From owner-freebsd-hackers Tue Mar 18 17:39:38 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 3D37937B401 for ; Tue, 18 Mar 2003 17:39:35 -0800 (PST) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59C1E43F75 for ; Tue, 18 Mar 2003 17:39:34 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net ([138.89.161.134]) by out002.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030319013932.GFDY6546.out002.verizon.net@bellatlantic.net>; Tue, 18 Mar 2003 19:39:32 -0600 Message-ID: <3E77CA50.60DA95D5@bellatlantic.net> Date: Tue, 18 Mar 2003 20:39:28 -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: Terry Lambert Cc: Nate Williams , 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> <3E750471.3498C9BE@mindspring.com> <3E765359.7FC6C541@bellatlantic.net> <3E769CCA.7E9BD340@mindspring.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [138.89.161.134] at Tue, 18 Mar 2003 19:39:31 -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 Terry Lambert wrote: > > Sergey Babkin wrote: > > # OK, let's suppose that our changes are finally complete, and nobody > > # else has committed any other changes in between > > cvs ci > > Suppose someone has? If you are so out of touch with the net you > need a cache, you are probably going to get a conflict, because It's very likely that the conflict can be cured by a simple "cvs update". > > So pretty much all I want is to make this procedure a bit more > > convenient, able to handle whole subdirectories as opposed > > to separate files. > > That's reasonable, but... you're rcs ci is a killer; it assumes > a local repostory in parallel. I guess you want a "multicvs", > which does checkins remotely or locally? I'm not sure what is a "multicvs", I just want to have some storage for the data before I get to commit it to the real repository. For example, suppose I write some code. Then I run a test on it and find some deficency that needs a non-obvious fix. At this point I want to save the present version somewhere before I start doing the fix, to make sure that I at least won't make things worse, and if I make them worse then I can always return back. After the fix is done and the test runs successfully, the final result can be committed to the central repository. > > As a model consider this: suppose we build a separate copy of the CVS > > binary, called "mycvs" that has the following differences from > > the normal CVS: > > That's actually grosser than the rcs version (IMO)... It's only an example to show an analogy. Though after thinking about it, it looks like a good model to start with and cover under the hood of cvs commands. > > > of verbatim copying of the repository. > > > > > > Incoherent: > > [ ... diagram ... ] > > > Why is it incoherent ? CVS checks that the version obtained by "cvs co" > > and then modified is still the top of the tree. If it's not, > > it will refuse to commit and will request you to do an update. > > I left out the (I thought) obvious part; ket me fix it: > > ,-------.-----cvsup(1)->,-------. > | Main |---- cvsup(2)->| Cache |<------. > | Repo | [CONFLICT] | Repo | | > `-------' `-------' | > ^ | | > | cvs co | > cvs ci(2) | cvs ci(1) > [CONFLICT] V | > cvs ci(3) ,-------. | > | | Work | | > `-------------------| Copy |-------' > `-------' > > Order: > cvsup(1) > cvs co > cvs ci(1) > cvs ci(2) [CONFLICT] > [FIX] cvs ci(3) > cvsup(2) [CONFLICT] > > In other words, you can't order commits with conflicts, without > going to the main repo first in call cases. That destroys your > intended disconnected use. When cvs ci(2) finds a conflict, the master repository is left unchanged. So cvsup will never see any conflicts. The real sequence would be cvsup(1) cvs co cvs ci(1) cvs ci(2) [CONFLICT - check-in fails] cvsup(2) cvs update [hopefully update resolves the conflict, or fix it manually] cvs ci(3) > The first time you get a conflict, your MYCVSROOT repository > is blown, and you won't be able to resyncronize it, without > replacing ",v" and "CVS/*" file contents. No. Two repositories in this example are completely independent. Their only connection is by checking in and out the same file manually. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message