Subject: Re: .cvsignore of *.gmo in binutils OK?
To: Greg Troxel <gdt@ir.bbn.com>
From: Frederick Bruckman <fredb@immanent.net>
List: current-users
Date: 02/03/2005 10:52:28
On Thu, 3 Feb 2005, Greg Troxel wrote:

>  Another data point -- the latest "unstable" version of "cvs" has an
>  "-X" option to the "import" command, the effect of which is to always
>  give the developer the suggestion to merge with "-j... -j..."
>
> I hadn't realized that this hint was only given if there are
> conflicts.  My view is that correct importing procedure is to do the
> merge checkout and commit regardless (and hence catch the R files).  I
> noticed that cvs now suggests using the point tag from the import as
> the second -j and the previous one as the first, instead of
> -jbranch:yesterday -jbranch, and I've long used explicit tags.

I like to add extra tags to the branches, <thing>-old and <thing>-new,
so I can do:

    cvs admin -n <thing>-old
    cvs admin -n <thing>-old:<thing>-new
    cvs admin -n <thing>-new
    cvs import -X ... <thing>-new <thing>-<version>

and the merge can then use "-j<thing>-old -j<thing>-new". Easier to 
type, and should be easier to script, too.

> I'm
> not clear on where NetBSD's procedures for importing third-party
> sources are documented, but perhaps doing the merge step (with
> explicit point tags) regardless of conflicts should be added.

There are guidelines for developers on the web

     http://www.netbsd.org/developers/

but some of the traditions are "informal", i.e., not documented.

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

Sounds dangerous. I've been playing around with the "import -X" thing 
in cvs 1.12.11, and it seems to work pretty well.


Frederick