Date: Mon, 17 Mar 2003 18:18:01 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Nate Williams <nate@yogotech.com> Cc: hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <3E7657A9.E7FA7FDE@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> <15990.19446.489565.532440@emerger.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?3E7657A9.E7FA7FDE>