Date: Sun, 6 Aug 95 12:26:04 -0400 (EDT)
   From: woods@kuma.web.net (Greg A. Woods)

   [ On Fri, August  4, 1995 at 21:15:19 (+0200), Niklas Hallqvist wrote: ]
   > Subject: Re: CVS & import scripts
   >
   > On the contrary, my CVS files doesn't get overwritten!  I can't
   > remember seeing any CVS files when I sup.  I've earlier supped from
   > sup.netbsd.org, and lately from wipux2.somewhere-in-germany, and I
   > haven't seen that problem.  Where do you sup from?  Anyway, this has
   > served as warning, I'll see if I shouldn't temporarily write-protect
   > the CVS dirs when supping.

   Two possibilities:

	   - wipux2 doesn't have CVS directories in the sup directory

Right! I'm almost 100% sure sup.netbsd.org don't either, didn't
check though.  I think the original problem were that Vax#8n supped
from another mirror, but I don't know.  In order to protect oneself, I
guess a write protection of the CVS dirs would be enough.

	   - sup ignores CVS directories because it seems your local copies
	   are newer?

Hardly, my CVS files in the supping dir is always only slightly newer
than the *last* sup.  If something were commited since then, the
CVS/Entries would surely be changed.

   > I do this as well, + the additions to make a diff since last sup to
   > merge into my working tree.  I prefer diff & patch to cvs merge
   > because I can easily browse through the diff.

   If I understand your procedure now you are doing something like this:

	   cd ~/sup
	   cvs co -ko -r BSD netbsd	# only done once
	   sup into ~/sup/netbsd
	   script_to_remove_add_commit_and_diff
	   cd ~/hack
	   cvs co -ko netbsd		# only done once
	   patch < ../sup/recent_diffs

Essentially, yes.

   I.e. you create a diff from ~/sup/netbsd of the changes between the
   latest sup and the one before.  You then apply those diffs as a patch to
   your local working directory instead of doing a join from the vendor
   branch.

Yes, I used to use cvs merge before.  The reasons for using a diff
were that the diff has some value in itself as it is small and easy to
transfer to other machines which carry source.  I also like browsing
context diffs to see what's been done.

   Do you always have a "clean" (i.e. nothing to checkin) working directory
   before you apply the patches?

Not always, but I try to checkin all my work separately in order to be
able to back the changes out later.  It's more because I don't want to
run a full cvs update over all the tree, as it takes so much time.
Therefore, I may forget checkins once in a while.  It has never turned
out to be a problem as my working tree doesn't need to be of
production quality.

   Do you tag anything in either your main branch or the vendor branch?

I have two branch tags, BSD & NH.  Earlier I tagged all the releases
with tags like CURRENT-950101 and NH-950101, but these cvs ops take
too much time as they need to update every file in the repository.  So
i wrote a small utility called "etag", which instead builds up a dbm
database with a mapping of path -> version for a tree.  I call these
dbm-files "external tags".  They're quite space-consumptive, around
1.5 MB per tag, but I have 5GB so I don't care.  Then I have an ediff
utility that creates context diffs out of two external tags.  It has
some more bells & whistles, and works quite nice, and much faster than
cvs tags for such a large tree.

None of this is of production quality, and all work is quite
specialized to my environment.  But, if anyone wants to glance at my
scripts, they're welcome.  I don't guarantee any kind of behaviour
though, expect the worst if you use it.

Niklas

Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG	WWW:   Here
Sweden