[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multilevel vendor branch import

From: Greg A. Woods
Subject: Re: Multilevel vendor branch import
Date: Mon, 27 Oct 2003 13:22:23 -0500 (EST)

[ On Sunday, October 26, 2003 at 12:59:48 (-0800), Mark D. Baushke wrote: ]
> Subject: Re: Multilevel vendor branch import 
> I have not tried to do it, but you might be able to use multiple vendor
> branches by using the -b switch to import and then have the vendor be
> LINUX_0_01, LINUX_0_10

'cvs import -b' doesn't actually work for the general case.

CVS vendor branch support only really works fully and properly with one
vendor branch and one "trunk", and _nothing_ more.

BTW, those are design limits, not bugs.  They are caused by the way CVS
tracks _the_ one vendor branch.  The multiple vendor-branch hacks
mentioned in the original paper about CVS-II left out all the magic that
would be necessary to make them work because of course it would have to
be real magic -- one cannot actually track multiple vendor release
branches with only one "trunk".  The CVS vendor branch support is a
quick and dirty hack that makes it relativley easy for one small group
of highly co-ordinated developers using one or a very few working
directories per module to track third-party releases and to relatively
easily merge "small" local changes into those new releases.  As has been
discussed here several times in the past, merging _MUST_ be done
immediately following an import if there is more than one working
directory in use since otherwise an update in any other working
directory will likely create a totally inconsistent revision set.  Note
also that local branches do not work properly with vendor branched
modules since the branch point for unmodified files becomes the vendor
branch and all kinds of havoc can fall out from that down the line as
new releases are imported unless all local branches are re-created after
every import.

If anyone wants to track multiple vendor release branches then the only
sane way to do it is to use multiple "normal" branches and to check in
new releases on their associated branches by hand (or by script :-).
There will be no conflict detection on check-in and merges to the trunk
(and/or to other local branches) must be done "manually" as there's no
automated tracking of _the_ vendor branch for locally unmodified files.

                                                Greg A. Woods

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]