[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Appropriate use of revision properties?

From: Paul Koning <pkoning_at_equallogic.com>
Date: 2006-01-12 23:08:12 CET

>>>>> "Bart" == Bart Robinson <lomew@pobox.com> writes:

 Bart> On 2006-1-12 Ryan Schmidt <subversion-2006Q1@ryandesign.com>
 Bart> 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.

 Bart> We do the same ("BugId: 1234,1236" at the beginning of a line
 Bart> for easy extraction, the post commit hook appends to the
 Bart> bugzilla entry). I think having to manually tie the bug to the
 Bart> changeset is a pain, much easier to just put it in your commit
 Bart> message.

Same here, except that the format isn't particularly tightly
controlled. I added a simple tweak to ViewVC to find bug ID
references (if halfway sanely formatted) and turn them into
hyperlinks. No hooks needed, which means it works fine with old
revision messages (even from CVS) -- so long as the string has
something vaguely like "bug 1234" in it anywhere, it'll get hooked to


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 13 00:29:22 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.