Subject: Re: CVS & import scripts
To: Simon J. Gerraty <sjg@zen.void.oz.au>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 07/01/1995 00:11:00
[ On Sat, June 17, 1995 at 06:01:12 (-0400), Simon J. Gerraty wrote: ]
> To: current-users@NetBSD.ORG
> Subject: Re: CVS & import scripts 
>
>[in some scripts posted as a shar file....]
> XI use "-I! " as otherise some files that you need (like
> Xbin/csh/USD.doc/csh.a) will be ignored..  The space after the ! is
> Xneeded.

Hmmm....  Which version of CVS are you using, and which patches have you
applied?

Certainly CVS-1.4A2 doesn't have this problem, assuming you use the
correct syntax:

	-I !

I.e. if you put a space between the option letter and the option
argument is necessary, you won't need a trailing space.  (Yes, I agree
that it's terribly confusing to have CVS conform to POSIX command-line
argument syntax, *except* where RCS options "show through".

> Xcd /d2/tmp
> Xcvs checkout -jNetBSD:yesterday -jNetBSD usr.src > /tmp/merge.out 2>&1
> X
> XYou can then go find all the files with conflicts.
> XEither grep '^C' /tmp/merge.out or find usr.src -name '.#*' -print
> XGo edit them to resolce the conflicts.  This is usually obvious.
> X
> XWhen happy. 
> X
> Xcd /d2/tmp/usr.src
> Xcvs commit -m"merged local changes with NetBSD-950508"
> Xcd ..
> Xrm -rf usr.src

I find it much safer and easier to use tags and the patch(1) command.
I've posted something similar to this procedure in the past to the
info-cvs mailing list, but I don't think it's in the FAQ or
documentation (yet):

	# assume last time round the vendor tag was "NetBSD-950427"
	# and I ftp'd the 950603 tar files of -current

	# tag the current state of local stuff....
	cd /usr/src	# my current working sources checked out
	cvs tag local-950427 .

	cd /ftp.d/NetBSD-current/tar_files/usr/src
	cvs import -I ! 'netbsd-current as of 950603' NetBSD NetBSD NetBSD-950603

	# this step is a bit heavy, and only necessary if you want to be
	# really pedantic and only move the default branch back on true
	# current files (i.e. not on locally modified but out-dated files)
	cd /var/tmp
	cvs co -r NetBSD-950603 NetBSD
	cd NetBSD
	cvs admin -bNetBSD . >/dev/null	# WARNING: no space after the '-b'
	cd ..
	cvs release -d NetBSD
	#
	# OTHERWISE you can just do this:
	cd /usr/src
	cvs admin -bNetBSD . >/dev/null	# WARNING: no space after the '-b'

	# now update the working tree to 950603 -current
	cd /usr/src
	cvs update -A -ko . | tee ../update-950603 2>&1

	# then make a patch file of the local changes....
	cd /usr
	cvs rdiff -c -ko -r NetBSD-950427 -r local-950427 NetBSD > patch-950427

	# and re-apply it/them
	cd src
	patch -p2 -s < ../patch-950427

	# if there are any conflicts....
	find . -name '*.rej' -print > ../patch-950427.rejects
	vi `cat ../patch-950427.rejects`	# you get the idea....
	cvs commit .				# etc....

	# and for good measure
	cvs tag post-950603 .

I find this far safer than the rcsmerge done by "cvs co -jXXX:yesterday
-jXXX module", since you get all the conflicts in a separate file, not
merged into the working file.  I also trust patch(1) more for some
reason, though I'm not sure why that is....

> XFinally, you should occasionally make sure you remove old files.

There's a much easier and safer way to do this.

Just before you apply the local patches (or at least before they are
committed), do this:

	cd /usr/src
	# the "-n" is obviously *very* important!
	cvs -nq tag -F NetBSD-950603 . | awk '{print $2}' > ../removed-950603
	for $file in `cat ../removed-950603` ; do
		if [ `cvs rlog -h $file | fgrep branch:` = 'branch: 1.1.1' ] ; then
			cvs rm -f $file
			echo $file >> ../really-removed-950603
		fi
	done
	cvs ci -m 'removed prior to NetBSD-950603' `cat ../really-removed-950603`

I.e. this will out-date files which didn't get the most recent vendor
release tag, so long as they have a vendor branch.  If they don't have a
vendor branch, they are locally added files.

NOTE:  I've not yet done this on the NetBSD tree, though I've done it
several times on CVS, BIND, Smail-3, and a few smaller things.

The one flaw I've found in this approach is that if the vendor adds a
file you've previously added locally it's impossible to keep the old
local revisions, even with Cyclic-CVS' "death" support.  You have to
completely remove the old local ",v" file from the repository before you
do the import with the vendor's file.

ATTENTION CVS HACKERS: What I'm thinking of doing is adding a "-B"
option to "cvs import" that resets the default branch to the vendor
branch on imported files.  This should save at least one pass over the
tree (and eliminate one more use of "cvs admin").  Does this sound OK?

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>