Re: multiple vendor branches

[Greg A. Woods]

[ On Wednesday, September 5, 2001 at 16:20:35 (+0200), Günter Zöchbauer wrote: ]
> Subject: multiple vendor branches
>
> I would like to manage the source of an application where I get versions
> from different developers.
> In the CVS manual the section how to handle multiple vendor branches
> descirbes this situation (I think)
> 
> I get only the files which differ from the base version from the other
> developers.
> Can I handle multiple vendor branches this way.
> What have I to consider.

CVS does not really support multiple vendor branches, at least not with
the vendor-branch support implied by use of "cvs import".

It logically cannot, at least not without the "cvs import" also
automatically doing its own private merges too.

The CVS vendor branch support implemented by "cvs import" is really only
suitable for propogating one set of local changes from vendor release to
vendor release (though actually the mechanism is the other way around --
new changes from a new vendor release are supposed to be merged to the
local trunk).  The only nifty magic is that "cvs import" does a form of
conflict detection to tell you whether or not you have to do a merge,
and if no locally changed files have been modified in the new vendor
release then you don't have to do a merge, just "cvs update".  If you're
doing anything more than that then I would most strongly suggest
avoiding "cvs import" like the plague it is!  ;-)

Your best option, at least if you're going to use CVS for this job,
would be to manually create a module with a baseline version of the
code, then manually create a normal branch for every vendor, then
manually commit and tag every vendor's new release to their associated
branches, and manually merge their changes to your own branch(es) and/or
the trunk.

Indeed you might even want to create a master branch (which might even
be the trunk) to which you first merge all the changes from all the
vendors), and then one or more private local branches to which you make
your own local changes, and to which you merge the master branch changes
to.  To be very pedantic you might want to create a local master branch
for every vendor branch, or a sub-branch from every vendor release
point, and use that to maintain any "standard" changes necessary just to
get the vendor code to build and work in your environment, then merge
from that to the master branch.

All-in-all tracking changes multiple variants of the same code base is a
rather large and complex accounting and maintenance task, even if the
code is relatively small itself!  ;-)

-- 
                                                        Greg A. Woods

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