RCS is cool, but cvs rocks! It will soak up entire subtrees, and includes
the ability to release patch files between 'changes'...it creates logs, and
all one has to do is put '$Id: $' and '$Log$' wherever they want the log/id
info just like rcs, and bwamo, there you go. Or you could not change
anything, and just use CVS (for the maintainer) to type:
cd current_linux_subtree
cvs commit
(and it'll find ALL changes, list the files that are changed, and ask for a
description).
What this does is 'checkin' the source files (after the repository has been
setup already) to the repository. The neat thing is that, one could make
available 'patch' files like normal, but one might also use a program called
'sup' to retrieve and 'supserv' to serve files from several sites to the
point of users saying:
sup
(and their /usr/src/linux is brought up to date auto-magically). Of course
there are other command line options, I've never had this setup, but I know
that NetBSD uses this, and I personally think it is cool.
I hope I've not been too brief to show off cvs's power. Oh, and one more
thing. CVS/rcs also has the ability to follow 'branches' i.e. two different
changes to the same source file, say while one is porting to a new platform
or something, and eventually the changes are worked into the same thing, but
for a time there are 2 different concurrent versions of the same file/set of
files called a 'branch'...enough sales pitch...I vote for CVS...
> If we could figure out a way for everyone to use it, it'd also make a
> standardized change log much easier. Just put $Log$ in a C comment and then
> always put decent comments when checking in revisions.
> I was also thinking I could write some quick tools generate the RCS tree.
> I'd sorta auto-manage the RCS tree from each new release. This doesn't help
> the changelog situation though (I thought about it before this topic came up).
>
> Of course there are always those 'global changes' that affected a lot of files
> that need some place to go. Perhaps a standard "Changes.here" file in every
> sub directory that would contain these? Then these could be collected for the
> global CHANGES file as well.
You don't need to write these tools to 'auto-manage the RCS tree'; they're
already written. --CVS :-)
-- Todd Fries...tfries@umr.edu http://www.cs.umr.edu/~tfries