Re: importing vendor branches

[Greg A. Woods]

[ On Friday, July 13, 2001 at 11:01:11 (-0700), Michael A. Fetterman wrote: ]
> Subject: Re: importing vendor branches
>
> There's no need to do anything special for these cases, as the current
> "cvs import" doesn't do anything terribly evil here.  The absence of a
> releasetag on the vendor branch is sufficient.  I define "sufficient"
> to mean that, if/when you do the merge and commit it, cvs will do the
> "cvs delete" on your mainline (or whatever other branch you might have
> been working on).
> 
> I attempted to be very precise in my wording in my previous email; the
> evil behaviors really only occur on *newly created* files during an
> import.

Have you ever dealt with a vendor module where files disappear and
re-appear frequently between releases?  I have (any of the *BSD pkgsrc
or ports trees are perfect examples), and I assure you there's a problem.

The current behaviour is, if not actually "evil", far less than ideal.  :-)

> I don't see the need for the dead revision.

Having the dead revision on the vendor branch means that you can always
clearly identify when a file deletion is merged to the local branch
(just as your trick with newly added files allows you to provide an
opportunity to explictly add them).  It also lets you know the file in
question isn't necessarily one with the previous vendor release tag on
it.
 
> If you checkout the releasetag, you won't get the deleted file.

Exactly -- that's effectivley the same "evil" as getting an added file
before you've merged it.....

Again the *BSD ports/pkgsrc trees are perfect examples because a missing
file is just as big an issue as any "new" file.  (The most common
disappearing and re-appearing files are the "patches/patch-*" files, so
a missing file means a bug/portability/security fix goes missing!)

> If you do either of the merges that I recommend, the merge process
> will delete the file for you (assuming you don't have a conflicting
> edit -- which you have to handle by hand anyway).  So what's the usage
> model that wants the dead revision?

Yes, but that doesn't avoid the kind of "evil" you're trying to avoid
when you try to be more careful about handling newly added files.  You
need to be able to explicitly merge all removed files just as you need
to explicitly merge all added files.  Any "automatic" handling prior to
an explicit merge is "evil" either way.  All's fine and good if you've
only one working directory, but should anyone do a checkout before your
merge is complete then it's a disaster waiting to occur.

> Agreed, but I haven't ever seen this to be a problem, either.  Its
> normally blatantly obvious which is the vendor branch tag.  Guessing
> the releasetags is a little more entertaining, but you can solve it
> pretty well with a simple naming convention.

You've just been lucky then.  Such blatant obviousness is only true to a
human, not to a program.  If files were to more commonly disappear and
appear and re-appear in the top level directory then it becomes a very
important problem since you can no longer automatically choose a file
that's guaranteed to have always been there in every vendor release (or
even at least have been there in the previously imported release).

> Maybe I'm missing something here.  Agree -- there's no N-way merge,
> but if you simply want the various vendor branches for *tracking*
> purposes of source code modifications from multiple vendors, it works
> fine.

You can check them in, but you can't check them out!  ;-)  (not
literally speaking, but figuratively speaking)

Generally speaking any scheme involving one local branch and several
vendor branches is not easy to manage if you do any merges from more
than one vendor branch.  Even if you always carefully tag the result of
every merge you've still got a maze of twisty little passages to
navigate if you wnat to try to figure out what came from which vendor,
and so on.

Yes, you can create multiple local branches too, but you must always do
every merge to every local branch, and you'll never get any automated
conflict detection on import.  I did some careful analysis a couple of
years ago that suggested if you create a local branch for every vendor
branch and then somehow merge every local branch onto one master local
branch you'll be able to maintain a combined release with enough
tracking to hand local changes back to each vendor.  However doing this
is best done without "cvs import" and the normal CVS vendor branches --
just create normal CVS branches and use "cvs commit" to add the new
vendor releases to their specific branches; and do all the merging and
tagging manually.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>