Date: Wed, 26 Feb 1997 10:51:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@mt.sri.com (Nate Williams) Cc: terry@lambert.org, nate@mt.sri.com, freebsd-current@freebsd.org Subject: Re: anoncvs server Message-ID: <199702261751.KAA28356@phaeton.artisoft.com> In-Reply-To: <199702260118.SAA26209@rocky.mt.sri.com> from "Nate Williams" at Feb 25, 97 06:18:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > You might even be able to create the 'magic' branch tag on your local
> > > machine, but I've not done it.
> > >
> > > Have you messed with it at all?
> >
> > Yes, but it looks like I can oly do one "magic" at a time without a
> > mirror repository and writing in an incremental checkin for a vendor
> > branch (possible with a "cvs log | sed ...", but takes too much local
> > space to do).
>
> What? The Repository files are not going to be modified if they're on
> the 'magic' branch, so why the need for a mirror repository? And, a
> vendor branch is totally un-necessary?
There is a difference between "a magic branch" and "the magic branch".
You guys have not stuck a tag into the main CVS tree, so I can create
"a magic branch" locally, but to create "the magic branch" takes someone
with commit privs.
The need for the mirror repository comes from me needing to support
incremental change-over as portions of my patches are (hopefully)
integrated into the main line source base. To remain operational,
a local system built from the regular sources with my "magic tag"
stuff merged in from my local use of the tag requires that I back
out changes as they are included:
FreeBSD | Terry
,-|
| |
Standard tree | |
| |-.
`-| |
| | My change #1
| |
|-'
|-.
| |
| | My change #2 <<depends on #1>>
| |
|-'
,-| <<Locally remove "My change #1">>
Standard tree | |
+ | |
My change #1 | |-.
`-| |
| | My change #2 <<depends on #1>>
| |
|-'
|
I can't do the ""Locally remove" steps against the magic branch without
a second tree.
If FreeBSD came in on a vendor branch initially, then it wouldn't touch
anything else I had done locally. Alternately, if it came in with a
predefined "magic tag", I could only make one change locally, and then
wait 9 months (the current time outstanding for the layering patches
being committed) before I could resonable reuse the "magic tag" for
another change. With the "magic tag" approach, I can only have one
set of dependent patches outstanding at one time.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702261751.KAA28356>