Is there a best practice for how to document the source code you're releasing?Currently, we have a table of the versions of the software, what SVN tag it's labeled as, what SVN rev that tag was created at and the SVN URL.Then, our CM (Configuration Management) department wants us to include a file listing of all the source files we're including for the .zip that we provide them which is just a zip of the tag we're releasing.I'm more fishing for ideas to update our print template, hopefully with good arguments to remove the file listing.
Source code prints at release
release;configuration management;distribution
Configuration Management (CM) folks don't think like programmers.  They think more like auditors.  The reason they want a list of the files is because they want to verify that they got them all.  Yes, this seems silly to a programmer, but it seems natural to someone who doesn't trust a single source of information.  Ideally, your list of files would not merely be an svn status -v or an ls -lR, but a human-mediated list of the specific files necessary to build your system and which you intend to provide.  Thus, for example, you would not list or provide the generated source files from a code generator that runs during the build process, even if they happen to be in your workspace at the time you build the ZIP file.