From owner-freebsd-hackers Mon Mar 17 15:18: 7 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 A477637B401 for ; Mon, 17 Mar 2003 15:18:05 -0800 (PST) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id B34EB43F75 for ; Mon, 17 Mar 2003 15:18:04 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net ([138.89.156.209]) by pop016.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030317231803.QZZK8278.pop016.verizon.net@bellatlantic.net>; Mon, 17 Mar 2003 17:18:03 -0600 Message-ID: <3E7657A9.E7FA7FDE@bellatlantic.net> Date: Mon, 17 Mar 2003 18:18:01 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Nate Williams Cc: hackers@FreeBSD.ORG Subject: Re: making CVS more convenient 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> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [138.89.156.209] at Mon, 17 Mar 2003 17:18:02 -0600 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 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