On Mon, Jun 26, 2000 at 10:24:37AM -0500, David Thornley wrote:
> 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.
Sort of. Its a bit more than that though, but you do have the
basic concept.
> 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.)
What you have done is the simple version of what Im looking for. Your
example wouldnt handle multiple branches (say 4 or 5) and merging
between them.
It is *significant* and anyone who has used a real tool like ClearCase
understands what Im talking about. Ill admit its really hard until
you have seen it in action and the power that it provides.
> 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.
Its a simple use model that doesnt work real well for more complex
things.
> 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.
Think beyond one branch to something like 4 or 5. This number of
branches is quite reasonable for very large projects doing
multiple parallel streams of development.
> > 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.
I want the tool to do this for me, I shouldnt have to. More importantly
my users shouldnt have to, primarily because they forget.
> 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.
Err, its new to CVS, but its standard on tools with real horsepower.
Dont get me wrong CVS is great because its free, but it also cant
compete with the industrial tools.
> 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.
It doesnt require an ounce of administration, but we gain back pounds
in functionality.
> 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.
Im glad things are working for you and the scripts you have written.
But Im more in favor of the tool have the underlying functionality
to do this.
If we had merge meta-data and directory versioning, CVS would kick
major butt even agains the big commercial guys. Fundamentally
*that* is what I would like to see.
-----------------------------------------------------------------------
John Cavanaugh Agilent Technologies
R&D Program Manager 1400 Fountaingrove Pkwy
CAD Data Store Santa Rosa, CA 95403-1799
Email: [EMAIL PROTECTED] Phone: 707-577-4780
707-577-3948 (Fax)
-----------------------------------------------------------------------
As I grow older, I pay less attention to what men say. I
just watch what they do.
-- Andrew Carnegie
-----------------------------------------------------------------------
