[ On Thursday, February 3, 2005 at 10:41:06 (-0500), Greg Troxel wrote: ]
> Subject: Re: .cvsignore of *.gmo in binutils OK? 
>
> I hadn't realized that this hint was only given if there are
> conflicts.

The hint is really bogus -- the merge after an import is really always
mandatory if there have ever been any commits to the local branch.

(the hint is also given wrongly....  sigh....  the correct merge is done
with the previous and current vendor release tags)

> It's arguably a bug that cvs import doesn't do the removal of
> no-longer-present files itself as part of the import.

Well it can't really do that safely -- that's part of the reason for the
manual merge after import.  Remember that "cvs import" effectively does
magic things to the trunk due to the "default branch" hack it uses.


Note though that "cvs import" should never be used whenever local
branches might also need to be made.  The default branch hack screws
things up.  Instead the vendor releases should be committed directly to
a normal branch and merges of vendor changes then need to be done
manually to each branch where they're need.

Note also that "cvs import" should never be used whenever the trunk
cannot be broken for any length of time.  If any local changes have ever
been committed the trunk is instantly, and without warning, put into an
inconsistent state immediately after any subsequent "cvs import", and
remains in that inconsistent state up until the vendor changes are
merged and committed to all locally changed files.  Instead the same
technique of manually commmitting vendor releases to a normal branch and
manually merging them to the trunk in a controlled fashion should be
used instead.

"cvs import" should only ever be used as a quick hack in very simple
environments where third party code is frequently updated and local
changes can be easily managed along the one trunk line.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>