Date: Thu, 3 Aug 95 23:51:54 -0400 (EDT)
   From: woods@kuma.web.net (Greg A. Woods)

   [ On Wed, August  2, 1995 at 02:40:38 (+0200), Rolf Grossmann wrote: ]
   > Subject: Re: CVS & import scripts
   >
   > on Sat, 29 Jul 1995 14:52:23 -0500 (CDT) VaX#n8 wrote 
   > concerning "Re: CVS & import scripts" something like this:
   > 
   > > So I suppose my questions are:
   > > 1) should the CVS directories really be sent to all sup'ers?
   > 
   > No, they should not. As I'm not using sup I have no idea whether it can be
   > avoided, though.

   BTW, if the sup tree didn't include the CVS directories, one could sup
   directly into a cvs working directory of the current branch, then just
   doing a checkin would update the local repository.  This would make it
   possible to save the big 'cvs imports' for the periodic "officially
   blessed" tar-balls.

I'm confused!  This is exactly what I am doing...  It works OK.  I
have a compilcated perl script that parses the sup log file and
appropriately adds, removes, updates, tags (although with my own
external dbm-based tag mechanism) the repository.  Then it makes a
diff file since the last sup (removing paths I ignore in my working
branch) and feeds it to patch on my working branch.  It's not of
production quality though, but to me that know where to pick up the
pieces when the script fails, it's allright.

I never do cvs import, just the standard cvs add/rm/update/commit
commands on the needed files, saves me a lot of time.

   This reminds me -- I'd *love* to be able to add to my RCS files the
   accumulated log entries for each file on at minimum each 'cvs import' of
   the tar-balls.  Unfortunately there's no easy way to generate or pass
   this data, even though it wouldn't be hard to have cvs use it.

I'd love this as well, maybe the commit filter could do a cvs log and
put in a hierarchy identical to the source tree.  I.e. for every file
A/x/y/z in the source tree, there is an always updated B/x/y/z which
is the output of a cvs log.  Then this hierarchy could be a separate
sup collection.  I'd really love this, but I can see the core has
better things to do, although this would not be more than a few hours
of scripting work, maybe even less.

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