Date: Mon, 17 Mar 2003 15:28:06 -0700 From: Nate Williams <nate@yogotech.com> To: Sergey Babkin <babkin@bellatlantic.net> Cc: Nate Williams <nate@yogotech.com>, hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <15990.19446.489565.532440@emerger.yogotech.com> In-Reply-To: <3E764A3C.FD4D2758@bellatlantic.net> References: <3E73DCF7.80490FA6@bellatlantic.net> <15988.49648.483313.383942@emerger.yogotech.com> <3E74CC37.DF83EE46@bellatlantic.net> <15988.52765.777500.37926@emerger.yogotech.com> <3E764A3C.FD4D2758@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > That's the plan for the next stage, provided that the first stage > > > goes well. I'm yet to play with CVSup and see if it can be > > > integrated there (as with system()) easily without making a lot > > > of changes to CVS itself. Otherwise I'm aftarid it's going to > > > be a large amount of work to duplicate this functionality :-( > > > > Another choice is to have the commit be also made to the 'cache' if and > > only if the remote (master) respository has accepted the commit. > > > > That way, the commit is made in both repositories using the same > > algorithm, so in essence they should be in sync. > > Yes, makes sense. > > > > Yet another idea is to be able to make "local commits" with committing > > > them to the central remote repository later. > > > > I'd do the reverse, since the possibility of synchronization problems > > are a huge deal. Imagine if someone 'snuck' in and made a commit in > > the master tree after your local commit was made, but before 'later' > > occurred and your cache pushed it out to the master tree. > > It gets handled in the same way as now: I believe, CVS checks > whether the checked-out version matches the top of the branch, > and if it does not then it refuses to commit and requires you > to make an update. So the same thing can be done for a "local branch": > check that its base version is still the top of the real branch, > and if so then commit. Otherwise require an update/merge. Except that it's possible that the 'local' cache is out-of-date w/respect to the remote repository, say if someone made a commit to it since the last 'synchronization' of the local cache. You don't want that commit to happen, since it should be allowed because the file is really not up-to-date w/respect to the master. The worst case is the committed change would conflict with the as-yet-unseen change on the master, so allowing the local user to commit it means that when the 'cache' attempts to commit it later, it will fail, and the 'cache code' is required to figure out how to extract the commit from the local cache, update the local cache, re-apply the (now conflicing) commit back to the local cache and somehow inform the user at a later point. *UGH* > > If you only allow the commit if it can occur locally, you're ensuring > > that the cache can't get out of date with local changes. I tried > > something like the above (cause it was easier to implement), and it > > worked most of the time. However, the times it didn't work it was a > > royal pain in the *ss to cleanup and get the original commit back out. > > Maybe I just was not clear: I think that making the commits in the > local copy on the real top of the tree is a quite bad idea. I think it's a good idea *IF and only IF* the commit to the remote tree works. That way, the local user isn't required to re-synchronize his cached tree agains the master tree, since their is a high liklihood that after the commit the user will also want to continue working on the same files. If no re-sychronization occurs, as soon as an 'cvs update' is done, the local cache must either re-synchronize itself (doing the exact same work as if it just done the commit), or the newly committed change will be reverted back out, since the local cache will now be out-of-date. > I want to get is some temporary versioned storage to play around > while I work on the code. After the code gets finished, it > gets committed to the master repository just as it committed gets now. What happens to the local cache *right after* the commit occurs? In essence, it's no longer valid right after a commit, since it's now out-of-date with the master (it doesn't include the newly committed changes). > > > Now I have to use RCS > > > locally for the temporary in-delevopment versions of file. Would > > > be nice to have a kind of a local branch which can be later committed > > > as a whole - in one commit per file, or by duplicating all the > > > intermediate versions with their messages. > > > > Agreed. The downside to the above method is that it requires network > > access to make a commit. However, it certainly simplifies the > > problem set. :) :) > > Well, at least the commit would get done in one batch (of course, > unless a conflict happens). Right, it's a step in the right direction. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15990.19446.489565.532440>