On 3/9/06, Bob Proulx <firstname.lastname@example.org> wrote:
> The subversion project HACKING file very nicely documents how to keep
> the svn log history in a useful change log format. If you have not
> read I highly recomend it. Additionally some coding standards (such
> as GNU) require an actual ChangeLog file to be included in source
> distributions. This means that generally similar information is
> available in two different places. Certainly with RCS/CVS a ChangeLog
> is really useful. But Subversion offers changesets and a unified log
> history of the project.
> I am curious
> a) if people are actively keeping a ChangeLog file so that it is
> available offline and in distributions?
> b) if people are using the svn log as the only change log?
> c) if people don't bother to maintain a project log?
> Depending on the project I have been continuing a) with a ChangeLog
> file in addition to the svn log. In others I do b) only making use of
> the svn log by itself. To me c) is anathema.
We've only recently started using SVN but we're doing a combination of
A) and B) for my application (an internal-only web-based application).
Because we're a public company in the US, we're subject to
Sarbanes-Oxley and have tons of paperwork required for each change to
the software. As part of this process, every time we do a migration
between environments, we have documentation of what files got moved,
and a high-level "what's this change for?" document. We also have an
item tracked in our helpdesk call-ticket system. All on paper. That
covers A, I think.
Now that we're using SVN, I'm encouraging committers to write useful
log messages containing the change # and/or ticket # and a description
of what changes they made. I've written a script to pull the last
week's worth of logs and produce an HTML page showing the log messages
and what files were affected. I think this is your B?
We'll be using the log produced from SVN on a regular basis to
reconcile changes in the environments against the requests logged in
our change tracking/helpdesk ticket system. If we had integrated
something like Trac into the system (which I may do on my local
installation, but it won't happen across the organization), we could
probably roll a lot of this all into one package based around B).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Mar 14 14:18:33 2006