Pardon me for jumping in... :-)
I generally agree with Jared and Matt on this, as I went through a
similar process in another life, and did end up using svn:log quite
effectively.
The issue, really, turned out to be developer bias to think "file
centrically" rather than "change centrically". Once we put process in
place to restrict a commit to a single logical change (generally
linked to a bug/issue), things got quite smooth.
Basically, what we did was develop a simple scripted app that allowed
a dev to fill in a form describing a change, listing anything they
liked, and cross-referencing a bug/issue. The script then generated a
small block of XML (which could be edited as desired using the app).
To perform a commit, the developer was required to submit the XML as
the log entry. A pre-commit then edited the script to add some
automatic information from the bug tracker database, check that the
bug was open for fixing, and that it was assigned to the dev doing
the commit. If all was ok, the edited XML was sent to the log file.
The bug was then marked as fixed (actually it was passed to the test
team).
We tweaked the XML so that a simple concatenate of any number of log
entries plus a small header/footer generated a valid XML file for
summary data. It all worked pretty well -- I'd recommend this as a
pretty robust workflow.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 11 08:04:34 2007