From owner-freebsd-hackers Mon Mar 17 20:14:30 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 BF27637B404 for ; Mon, 17 Mar 2003 20:14:26 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA7CA43FA3 for ; Mon, 17 Mar 2003 20:14:25 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0217.cvx22-bradley.dialup.earthlink.net ([209.179.198.217] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18v8UV-0004qe-00; Mon, 17 Mar 2003 20:14:21 -0800 Message-ID: <3E769CCA.7E9BD340@mindspring.com> Date: Mon, 17 Mar 2003 20:12:58 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sergey Babkin 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a46deee49447c996d67c94da6d3b3462ce666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c 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 Sergey Babkin wrote: > Terry Lambert wrote: > > Not really possible, without CVSup coming onto a vendor branch instead > > Actually, I was thinking of the opposite: doing all the changes > on a vendor branch (or in some separate local repository altogether), > then merging them into the main branch. Think of the following > sequence that can be used now: [ ... ] > # 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 people are tweaking things all the time, sometimes, it seems, rearranging the deck chairs to get their name in CVS lights. 8-). > 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? If you want all of your checkins checked in, then you could do this with a shell script wrapper that knew about "link up" on your network interfaces. Is that a possible solution for you? > 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: > > 1. Instead of the variable CVSROOT it uses MYCVSROOT > 2. Instead of the metadata subdirectory name CVS it uses the name MYCVS > 3. It never touches any of the keywords (such as $Id etc.) > 4. When asked to add a file, it automatically creates the whole > path of intermediate directories for it. (How does it know where > the checked-out tree starts ? There are many more or less > obvious and convenient ways to do that, so let's leave this issue > alone for now). > > Then in the example above you can do > > export MYCVSROOT=~/tmp/cvsroot > mycvs init > > And do everyhing as in the previous example, only replacing rcs > with mycvs (and obviously you wold need to do "mycvs add" before > the fiest "mycvs ci"). That's actually grosser than the rcs version (IMO)... > > 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. 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. In other words, any time, there is a "checkin to main repository" conflict, your foot goes "bye bye"... Make sense? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message