This is not an elegant solution but it works for me.
After getting a sucessful build, I tag the files with a unique build
id (so I can check them out later if needed of course.) I also run
"cvs status project" (where "project" is the module) to get the
information for every file checked out. I use a perl script to filter
that information so I get one line per file with the name of the file
and the revision number of the file. This is sorted and saved to a
log whose filename matches up with the revision tag I just applied to
the build. The commands would look something like this:
cd sandbox
cvs co project
make
cvs tag build_id project
cvs status project | perl_script | sort > /logdir/build_id
The file ends up having contents like these two lines:
project/foobar/Makefile 1.2
project/foobar/README 1.1
If I want to see what files changed between builds I can use a text
file difference tool. In your case you could then do a "cvs log" for
each file that changed.
Disadvantages are the extra time the build takes (the status takes as
long as the build) and the disk space usage. Advantages are how
quickly I can get information when it all has been logged and I have a
record of revision numbers for a build in case I delete a tag or a tag
is forced to point to an incorrect revison number.
Oh yes, the perl script takes into account new files and files moved
into the attic by moving the "Attic" file level from the filename into
a comment that follows the revision number.
Regards,
Rick Parker
