> > > 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* > > Yes, this is way too complicated and error-prone. This is why I don't > want to change the cache without changing the master in the same way > first.
I think we're in *violent* agreement at this point. :) > > > > 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 > > Agreed. So the commit would essentially work as a commit plus > resynchronization of a subset of files in the cache. *grin* I love it when a plan comes together. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
