[ On , August 3, 2000 at 06:29:03 (+0200), Assar Westerlund wrote: ]
> Subject: Re: lib/10739: crypto lib doesn't compile
>
> How should I have done this to avoid the delay between importing the
> new code on the vendor branch and fixing the build stuff?
> 
> I did basically:
> 
> cvs import -m 'import of heimdal 0.3a' basesrc/crypto/dist/heimdal HEIMDAL v0-3a
> cvs update -j ...
> <merge the bits from dist/heimdal>
> cvs commit
> cd crypto/dist/heimdal && cvs update
> < hack and make it build >
> cvs commit -m '...'
> 
> How can I make cvs just do the merging that it does with `cvs import'
> and then be able to hack the rest of the pieces into shape before
> comitting the whole thing?

You can't.  Anyone else who comes along and does a 'cvs update' is going
to get all of the new crud from the vendor branch that's not in conflict
with local stuff.  This is the way CVS vendor branches work, by design.

This is also a perfect example of one of the reasons why mixing
``normal'' CVS development processes (eg. with normal branches) in with
a vendor-branched module, *especially* when that module is normally used
as one small part of a larger working directory, is not very wise, to
say the least.  Unfortunately at this late date the NetBSD CVS
repository has an enormous mess of this stuff scattered throughout.

The only correct way to do this with CVS is to create an explict
"vendor" branch (that's not a CVS-vendor-branch, i.e. not 1.1.1) and
then you can avoid the magic CVS vendor branch handling that's causing
this (but of course then you have to manually do all of the imports with
"cvs add", and merges have to be done much, *much*, more carefully).

Perhaps a flag day should be declared and all new third-party
code should move to manual imports and merges and the NetBSD CVS server
should be hacked to barf on "cvs import" (perhaps only if in the 'main'
module or something).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>