[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: importing vendor branches
From: |
Michael A. Fetterman |
Subject: |
Re: importing vendor branches |
Date: |
Fri, 13 Jul 2001 11:01:11 -0700 |
> 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