Nate Williams wrote: > > > 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. > 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. All 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. > > 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). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
