Date: Mon, 05 Aug 1996 15:50:47 -0700 From: John Polstra <jdp@polstra.com> To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Announcing CVSup: Intelligent SUP Replacement Message-ID: <199608052250.PAA17655@austin.polstra.com> In-Reply-To: Your message of "Mon, 05 Aug 1996 15:10:39 PDT." <199608052210.PAA12079@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608052250.PAA17655>