Date: Mon, 17 Mar 2003 16:20:53 -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.22613.286738.863656@emerger.yogotech.com> In-Reply-To: <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> <3E7657A9.E7FA7FDE@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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 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.22613.286738.863656>