From owner-freebsd-hackers Mon Mar 17 15:20:58 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EF4437B407 for ; Mon, 17 Mar 2003 15:20:56 -0800 (PST) Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1332A43F75 for ; Mon, 17 Mar 2003 15:20:55 -0800 (PST) (envelope-from nate@yogotech.com) Received: from emerger.yogotech.com (emerger.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA01561; Mon, 17 Mar 2003 16:20:53 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by emerger.yogotech.com (8.12.6/8.12.6) id h2HNKrok003093; Mon, 17 Mar 2003 16:20:53 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15990.22613.286738.863656@emerger.yogotech.com> Date: Mon, 17 Mar 2003 16:20:53 -0700 To: Sergey Babkin Cc: Nate Williams , hackers@FreeBSD.ORG Subject: Re: making CVS more convenient 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> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > 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