John P Cavanaugh wrote:
>
> > > I may be slow today, but I don't see how merging the metadata is going
> > > to accomplish all this [stuff that vendor branches do].
>
> Merge Metadata can serve the same function as the vendor branch.
>
> Typical scenario, a local copy of an open source project, maybe say cvs.
> Ill describe a scenario of how you could use this hypothetical cvs to
> develop the features to get to the hypothetical version.
>
What you are proposing is to use the trunk as the vendor branch, and
the equivalent of keeping a "last-merged" tag on it to merge onto
a branch. This is the sort of functionality that took me three
days or so to write perl programs to handle (interfacing with CVS,
of course) that were tailored for our development process and which
catch a lot of common errors in process and procedure.
Specifically, the "merge metadata" idea seems to be nothing more
than keeping a "last-version-merged" tag on each branch, and updating
it accordingly. (Except that it is not shown to have the ability
to *not* merge a change that should not be merged - whereas it's always
possible to move the "last-version-merged" tag without actually merging.
Presumably such a facility would have this ability, but it's still
not looking to me like a great improvement.)
> - You import the initial rev onto the main branch. (Say 1.10.8
> or whatever)
>
> - You create your own private branch (called named_trunk) to make your
> changes for say the naming of the main trunk
>
The CVS way, you've now got a labelled vendor branch and a main branch
you can do development on. Your way, you've got a main branch that's
got the vendor release, and a private branch you can do development on.
In the event that you've got two external products you're combining,
you have problems your way, none the CVS way. This may not matter.
> - Lots of work happens on cvs to fix bugs etc, or to add new
> subcommands like lsvtree.
>
> - You now import a new rev onto the main branch (Say 1.10.9
> or something)
>
> - Now to update your private branch you just do a merge from the main
> branch by doing something like "cvs up -j main"
>
> - Even more work happens on cvs to fix bugs etc, or to add new
> subcommands
>
> - You now import a new rev onto the main branch (Say 1.10.10
> or something)
>
> - Now to update your private branch you just do a merge from the
> main branch by doing something like "cvs up -j main". But the
> difference now is that it only merges in the differences from your
> last merge.
>
However, the recommended "-j:yesterday" works very well in this
scenario, provided of course that you don't import vendor branches
more than once every day or two. We don't here; I don't know about
your shop.
So, now that you've described this, what is the difference between
what you've described and what CVS does? The difference I can see
is that you want to put the vendor releases on the main trunk, whereas
CVS puts them on a labelled branch. Obviously, in this case, merged
metadata can do what CVS is doing. However, I really don't see that
there is any advantage to doing so.
> This model also allows you to have multiple private branches doing all
> kinds of various things that are unrelated to each other. Perhaps
> one to add rename support, another to add merge meta-data etc.
>
And the difference between this and intelligent use of CVS would be?
We can do things like that already. It requires a little intelligent
use of tags. This use can be codified into wrappers that people
will use instead of raw CVS commands. Nothing you've described is
beyond what can be done with intelligent tag use. It would probably
be easier to use for somebody starting with CVS being installed and
projects starting yesterday, but that's a pathological case for any
support software.
There are instructions in the Cederqvist about how to do this sort of
thing. This isn't anything new, or anything that hasn't been considered
before.
So, merging metadata (as you put it) would be a convenience, but as
far as I can tell nothing more. If it requires more active CVS
administration, it might well be a loss.
> > And how did merging (meta)data get into this thread? I'm not signing
> > up for _that_, no matter how many people refuse to change the
> > subject line. ;-) Waaaay too hard, and I'm not really sure I even like the
> > idea anyway.
> > -- steve
>
> I agree its hard, but its very useful for big software projects with
> multiple parallel lines of development its essential.
>
What do you mean by "multiple parallel lines of development"? How
parallel? (ISTM that, if they don't track each other, they're going
to diverge, and that will destroy the "parallel" part.)
Would it qualify to have head branch and two or three releases on which
development is happening? This is not giving any great amount of
trouble.
> If you havent done multiple parallel lines of development (ie. like 3
> or more) you wont see the benefit because you havent felt the pain.
> Serious tools like ClearCase have these, until cvs does it wont be
> considered in the same league as ClearCase.
>
Um, there hasn't been all that much pain. I can see how there would
be if we weren't using a tool like CVS, but with CVS we've got this
stuff organized so almost all the branch synchronization stuff is
routine.
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
