Re: Again: multiple vendors

[Greg A. Woods]

[ On Thursday, March 3, 2005 at 21:31:58 (+0100), Baurzhan Ismagulov wrote: ]
> Subject: Re: Again: multiple vendors
>
> On Thu, Mar 03, 2005 at 03:58:42AM -0500, Greg A. Woods wrote:
> > 
> > Do not use "cvs import".  It can not work as any part of what you want
> > to do.
> 
> Hmm, Cederqvist recommends it in
> https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_13.html#SEC108

Read again.

There's nothing in there about multiple vendors (or if there is and I've
forgotten about it, it's blatantly wrong and misleading).

Multiple vendor branches CANNOT work for what you want.  Period.

The idea of using multiple vendor branches was hinted at in the original
CVS-II paper, but the design of how vendor branches work prohibits them
from working properly with multiple vendor branches.  Any attempt to
extend that hint into the modern documentation is a mistake.  Just
because "cvs import" lets you specify alternate branches doesn't mean it
is sane to do so.

(indeed vendor branches don't mix well with normal branches either)

"cvs import" is a very cheap-trick hack that works well for trivial
maintenance of local changes to third party modules.  It does work very
well for that job (I've used it for ten years or more on gigabytes of
source), but it's still just a very cheap-trick hack.


> I thought about that, but this is going to be a bit time-consuming due
> to:
> 
> 1. Added and deleted files: I have to track them manually when I apply
>    the delta for a new upstream release. I have to grep for 1970 and add
>    / remove the files.

That part can _very_ trivially be scripted and totally automated.

The only hard part is merging with your changes IFF you locally modify a
removed file, etc.

BTW, if your code suppliers add and remove files frequently, and
especially if doing so causes them to diverge significantly from each
other, then your hope to use a tool like CVS to more easily merge
changes from each supplier into one common baseline is bound to fail
eventually (unless you have a _lot_ of patience and you are willing to
do a _lot_ of manual and complex merging).


> 2. CVS keywords in the upstream patches. I have to import the previous
>    and the current release into a temporary module and produce the diff
>    with -kk.

Yeah, so?  This problem exists regardless of how you deal with third
party code that also uses RCS keywords.

Also, you can trivially preprocess the third-party code to remove or
adjust those keyword instances if you want to avoid this hassle all
together.


> That is why I was wondering if the method described in the manual could
> work for me.

You say you want to do something that is not described at all in the
manual, so nothing in the manual can work for your purposes.

(The manual probably should be fixed to be more descriptive of these
issues and to give procedures and processes for dealing with these kinds
of issues, but it hasn't been yet.)

-- 
                                                Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>