From owner-freebsd-hackers Mon Aug 5 18:43:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05403 for hackers-outgoing; Mon, 5 Aug 1996 18:43:54 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA05375 for ; Mon, 5 Aug 1996 18:43:49 -0700 (PDT) Received: from austin.polstra.com by mail.crl.com with SMTP id AA28853 (5.65c/IDA-1.5 for ); Mon, 5 Aug 1996 15:53:43 -0700 Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id PAA17655; Mon, 5 Aug 1996 15:50:48 -0700 (PDT) Message-Id: <199608052250.PAA17655@austin.polstra.com> To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Announcing CVSup: Intelligent SUP Replacement In-Reply-To: Your message of "Mon, 05 Aug 1996 15:10:39 PDT." <199608052210.PAA12079@phaeton.artisoft.com> Date: Mon, 05 Aug 1996 15:50:47 -0700 From: John Polstra Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > CVSup is able to merge new deltas and tags from the server with deltas > > and tags added locally on the client machine. This makes it possible > > for the client to check local modifications into his repository > > without their being obliterated by subsequent updates from the server. > > John Polstra is a stud. Thanks! Oh, hang on a second, I gotta go shave again. Fourth time today, what a pain. :-) > Do you happen to have a small writeup of local vs. remote changes for: > > 1) get source tree using CVSup > 2) Make local changes using a tag > 3) Make more local changes using a second tag > 4) Update source tree with remote changes > 5) Merge updated code with tags to get new versions of tags Not really, but I'm glad you brought this up. I've been thinking a lot about the logistics of local modifications, and I could use some advice. First: Terry, I'm sure you understood this, but for my own peace of mind I want to clear up a potential source of misunderstanding in the way I worded that part of the announcement. I think most people will understand what I meant, but I don't want to confuse anyone. When I said it can merge new deltas from the remote side with deltas added locally, I meant this: If you've added new deltas A and B locally, and somebody else has added new deltas C and D remotely, you'll end up with all four, A, B, C, and D. It will _not_ do code merges to combine two sets of changes into a single delta; i.e., it doesn't do what "cvs update -j 1.1 -j 1.2 foo" does. Now, on to the logistics ... If I add, say, revision 1.15 locally, and somebody else adds a revision 1.15 remotely, something has to give. So we need a set of conventions, probably supported by some small changes to cvs itself, to avoid those kinds of collisions. My current thinking is that local modifications need to be made on their own branches, and cvs has to be changed so that it won't create those branches without a special option. Something like this: 1. Stake out a range of revision numbers that is reserved for local modifications. For example, we could say, branch numbers >= 1000 are reserved for local modifications. This would include all revisions a.b.1000.d, a.b.c.d.1000.f, a.b.c.d.e.f.1000.g, and so forth. 2. Modify CVS so that it would never create the reserved revision numbers, except by explicit command. 3. Further modify CVS to add an explicit flag for creating a new reserved branch. This would probably be a flag to the "tag" and "rtag" commands, similar in spirit to the existing "-b" flag. Under this scheme, you could create your local branches at will, commit to them freely, and be assured that updates from the remote repository would not clobber them. I've looked at cvs, and this would be pretty easy to do. Do you (all of you out there who are interested) think it's a workable approach? Any better ideas? > I would also like to see a collection that carried administrative files > for SUP/CVSup that was used for sample files and never changed ID so that > you could track the changes. If comment characters were supported in the > SUP file, you could comment the collections you didn't want from the > universe of available collections, and: > > 1) SUP collection file > 2) Merge local changes (comments and local location and base) via > CVS command (Item #5 in process above) > 3) SUP the rest using never-stale information I like this idea a lot, although I don't think it'll work out-of-the-box. SUP files do support comments (with a leading "#"). But cvs can't do the kind of merge you'd need. It only merges on a line-by-line basis; it couldn't merge a local location and base into a new collection line from the remote site. Another possibility would be to add a syntax to the supfiles for specifying global overrides of individual parameters in the collection lines. E.g., at the top of the supfile: $override host=cvsup2.freebsd.org prefix=/home/terry/cvs > John, this is *wonderful* enabling technology... It's been a whole lot of fun to work on, that's for sure! Thanks for the comments. -- John