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