Re: importing vendor branches

[Michael A. Fetterman]

> There's only one problem though....   How do you handle removal and then
> subsequent re-addition of a file on the vendor branch?  I don't think
> your current script does that from what I can understand of it on one
> quick read....  How about if there were previous local changes to a
> removed file that's now being re-added?  I'm pretty sure you don't
> handle the latter at all....  All of these conditions need to be
> recognized and handled properly.

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.

> The problem here is that there's never a "dead" revision added to the
> vendor branch.  The only clue is that the previous vendor tag does not
> appear on the file.

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

If you checkout the releasetag, you won't get the deleted file.

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?

> Unfortunately there's no guaranteed way to find the previous vendor
> tag.  You have to assume that it's in the first file you look at....

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.

> > The script is particularly designed to work correctly in the presence of
> > multiple cvs vendor branches (ala "cvs import -b"), but does nothing to fix
> > the brain dead requirements of that switch for a numeric branch number.
> 
> Multiple vendor branches don't (can't) work anyway -- they should just
> be removed (they were long ago deprecated).  You can't do N-way merges
> where you have more than one ancestor version, at least not in a single
> pass with existing tools.

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.

Michael Fetterman