Now that we've been running SVN for a few months, my next task is to
set up a process such that I can pull a log monthly showing what files
have been changed in our production environment in the previous month.
Our setup is SVN 1.2.3 on Win32, served via Apache. Builds/releases
of our web app in our 3 environments (dev, beta, production) are
handled by Anthill - upon successful deployment in dev, we cut a tag
for beta. Upon successful deployment in beta, we cut a tag for
production. Production deployments are pulled from the latest tag
that beta cut (we manually track in our paperwork what beta tag was
promoted to production).
I'm thinking of changing this such that dev deployments create a dev
tag, beta creates a beta tag, and production creates a production tag
for clarity in the logs, etc. We're early enough right now that doing
this is no big deal.
I've spent a couple days now going through SVN log and info output
trying to piece together a script that can tell me "Between May 1 and
June 1, these files were changed in production" and it's been very
slow going. I think I'm going about it wrong.
I've had 2 other ideas:
1) Write a post-commit hook which writes out to a separate file with
check-ins on the trunk and the production tag.
2) Write a script to check what production tags were created in the
given month, and use svn diff to compare those tags against the last
tag for the prior month; grepping on "Index:" will get me a list of
filenames.
Our change management controls (Sarbanes-Oxley) only require that we
identify what files changed and an explanation of why - a full diff
isn't required. I already have a pre-commit hook rejecting
message-less commits and have asked committers to include a change
tracking number with each change - this combination should suffice for
our SOX requirement.
Property changes don't need to be reported, as they don't affect the
function of the code in the production environment. Alexey Neyman
recently encountered a similar situation [1] and if I pursue option 2
above, I'll definitely be in contact with him to discuss the filter he
mentions possibly developing. Option 1 would let me more easily
ignore those property changes.
Option 2 also results in more work as far as tracking down log
messages for the changed files.
If it makes any difference, I'll be implementing this in either
JScript (most likely), VBScript (less likely), or batch/CMD scripts
(miniscule chance) to run on Windows, calling the svn command-line
client and parsing the output (either XML or plain-text; I can parse
either via JScript & objects available in WSH). For both the report
generation side and the hook script (if one is written). I want to set
this up with a minimal footprint and no additional software required
to be installed.
How are others doing this (or how would you do it)?
[1] http://article.gmane.org/gmane.comp.version-control.subversion.user/49352/match=properties
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 5 17:14:43 2006