Date: Mon, 05 Aug 1996 19:31:02 -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: <199608060231.TAA18672@austin.polstra.com> In-Reply-To: Your message of "Mon, 05 Aug 1996 16:31:31 PDT." <199608052331.QAA12309@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> OK, what about revision history?
Speaking of history, the cvs log files might represent a problem. I
hadn't thought about them.
> Specifically:
>
> 1) main line source tree
> 2) Terry makes local revisions
> 3) import Terry's local revisions into the main line source tree
> to make an updated main line source tree
> 4) resulting main line tree contains 'N' additional revisions to
> ufs_vnops.c (or whatever)
I don't think you'll be able to do it that way, without requiring a
whole lot more complexity than I had in mind. I think, to make it
workable, every branch including the main branch (the trunk) will have
to be exclusively owned by either the remote side or the local side. I
can't see how both sides can be adding deltas to the same branch, without
running into each other.
What I have in mind is more like this:
1. Main line source tree
2. You decide to make local revisions. First you create a local
branch, something like this:
Create the branch point tag:
cvs rtag LOCAL_SMP_BP <module>
Create the local branch, using the not-yet-implemented "-B" flag to
give it a reserved local revision number.
cvs rtag -B -r LOCAL_SMP_BP LOCAL_SMP <module>
Checkout your new branch, which, so far, is the same as the official
sources:
cvs co -r LOCAL_SMP <module>
3. Edit, commit, edit, commit. The commits go onto your local branch.
4. Meanwhile, run CVSup whenever you want to. New deltas will come in,
but they won't interfere with your stuff.
5. When you want to bring new revisions from the official sources into
your personal version, you'll have to do a merge:
cvs update -j 1.42 -j 1.44 foo.c
cvs update -j 1.37 -j 1.40 bar.c
...
(resolve conflicts)
...
cvs commit
Ick, not very nice. It's the same problem that led to the demise
of the -stable branch. The merges get awkward pretty fast. It
might be a bit easier if you made clever use of a couple of additional
tags, to keep track of where you did your last merges from on the
main branch.
Well, anyway, I think anything more complicated than this would be
another _big_ project.
> How seperate is the insertion code? Could it be run locally between
> two trees?
The code that does things to RCS files is _very_ separate. Hey,
the language ain't called ***Modula***-3 for nothin'! You'll see
what I mean if you look at the sources, specifically, "RCSFile.i3"
and "RCSDelta.i3" in the "suplib/src" directory. They contain the
public interface for dealing with RCS files. You'll be able to
understand it, even if you don't know the language.
> > $override host=cvsup2.freebsd.org prefix=/home/terry/cvs
>
> Yes! This is what I wanted anyway, but I didn't want to sound greedy... 8-).
I don't think it would be a problem. I've always hated how you
have to specify everything for every collection in a supfile. I'd
like to be able to specify defaults and overrides both, maybe even with
wildcard patterns for matching collections to which they should apply.
Actually, I hate almost everything about sup, operationally. But
I didn't want people to have an excuse not to try CVSup, so I made
it more-or-less compatible with sup's supfiles. :-)
-- John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608060231.TAA18672>