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