Re: importing vendor branches

[Greg A. Woods]

[ On Thursday, July 12, 2001 at 12:56:11 (-0700), Michael A. Fetterman wrote: ]
> Subject: Re: importing vendor branches
>
> One proposed fix (for #1 and #2 only):
> For each file newly created by a cvs import, do a "cvs delete" on that file.
> That will cause its default branch to be set back to the mainline, and will
> effectively remove the unwanted file contents from the mainline.

(There is no real "cvs delete" command, but I susepct you mean "cvs rm"...)

I like this idea.  I will try it myself on my next NetBSD import....

Pitty you wrote it in perl though....  :-(  If I end up doing it manually
enough times myself I'll try supplying a portable shell version....  I
will rely on the new "cvs rlog" though, and the output of the "cvs import"
(i.e. I will write a wrapper to replace direct use of "cvs import")...

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.

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.  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....

Perhaps if "cvs import" did add a "dead" revision, and/or if the
previous vendor tag had to be supplied on the command-line too.....

Hmmm....  many things to think about!

> I believe this should be implemented as an additional switch to "cvs
> import" (or, IHMO, as its default behavior, with a switch for backwards
> compatibility),

I think if a corrected version of your proposal were implemented as a
part of "cvs import" then it could be not only the default, but be the
only behaviour.  I don't see how anyone could even depend on the
existing behaviour (unless they *never* make local changes!  ;-).

I don't think any backwards compatability would be broken other than the
fact that the initial merge needs to use '-j1.0'.  I think this advice
could safely be given at the end of the "cvs import" output if there's
only one previous tag on the vendor branch (and that existing advice
needs changing anyway to specify the previous vendor tag in any case).

I think this will sove remaining problems I see with handling new and
removed files from vendor releases.

> 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.

-- 
                                                        Greg A. Woods

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