On 2006-1-12 Ryan Schmidt <subversion-2006Q1@ryandesign.com> wrote:
> > My thinking is that by doing this, we can more easily query subversion
> > logs later to determine what changes were made for ticket 1234. The
> > alternate would be to have a standard commit message format and
> > require everyone to use it; however, that would require parsing every
> > commit message to find the ticket number I'm looking for.
> As far as I know, most people put that kind of stuff into their
> commit message according to a particular format. For example, we
> require all bug numbers to begin with a hash mark (e.g. "#1234") so
> that it could be automatically parsed out by a tool, should we at
> some point get the desire to write one.
We do the same ("BugId: 1234,1236" at the beginning of a line
for easy extraction, the post commit hook appends to the
bugzilla entry). I think having to manually tie the bug to the
changeset is a pain, much easier to just put it in your commit
The ability to easily go back and edit the svn:log revprop makes
it simple to go put bugid: tags in if someone forgets (we put
them at the beginning of a line for easy extraction).
However, Subversion doesn't currently have log message templates
so you either have to hack the code (what I did) or have
thorough user-education and enforcement about what fields to add
to commit messages. I plan to help fix the log templates thing
since we use them heavily. svn issue 1973 tracks the templates
> I believe some of the web-based repository viewers import information
> about each revision into their own database whenever the commit takes
> place, via a post-commit hook. You could use one of those tools, or
> write your own, such that you build up your own database which could
> then contain anything you like, including all revision properties.
> Then you could query your database for that information.
Hey that's a good idea. viewvc does the database thing and it
would be pretty straightforward to customize it to store the
issue-id from the commit message. Then you could do queries
like "what bugs were fixed on this branch", or "what branches
had fixes related to bugid 1234" (although for us that info is
already in the bug report, just spread around in the comments).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jan 12 23:08:01 2006