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

RE: Re: Simple Label=RevisionID Discussion

From: Bryant Eastham <beastham_at_pewla.us.pewg.panasonic.com>
Date: 2006-11-29 04:51:05 CET

Tim Hill wrote:
> Scenario: I have a bug-tracking system that uses global IDs for each
> bug (regardless of projectID), iow just like Subversion handles rev
numbers.
>
> When in lock-down, I wish to track bug fixes against checkins, so for
> auditing purposes I want the following: (a) record the bugID in the
commit
> and (b) record the commit rev# in the bugID.
>
> Where do I store this meta-data (the bugID) in Subversion, today?
> The log message? Yeah, let's join the "prayer based parsing"
> movement. A revision property? Disabled by default and *bad* since if
> I turn them on I can also retroactively change the audit trail.
>
> What I really want, of course, is commit-time metadata that is
immutable.
> To me, that's a label. <sarcasm> Apparently, though, this is a _bad_
idea.
> Hacking a bunch of ad-hoc syntax into an overused log message field,
though:
> that's a _good_ idea. </sarcasm>
>
> Or, what I want is this:
>
> svn commit ... --revprop "BugID=2788"
>
> What's so silly about that?

I'm not saying that it is silly, but I for one don't understand your
(possibly hypothetical) process. You imply that at *commit* time you
*know* in an *immutable* way that a bug is fixed? It would seem that the
best that you commit is a "hope", that you must build and verify, and
then you may *label* (if you care) and enter a revision (and possibly a
build path) into your bug tracker.

At least that is how we do it. Cheap copies to the rescue (if we
want/need the label, which we rarely do).

The difference is that we keep the bug information primarily in the bug
tracker, and the source code information in the revision comment. Our
engineers do put the bug number in the commit comment only to justify
the commit (if in code freeze), not for tracing. The bug tracker points
to the revision that the bug was fixed in, meaning the revision of the
build in which the bug was *verified as fixed*. There may, in fact, be
several commits between the "bug fix A" commit and the "build in which
bug A was verified".

Everyone has their process. If you can't make your process work with the
tool, then you change the process or the tool. It is almost always
easier to change the process IMHO.

Bryant Eastham
Chief Architect
Panasonic Electric Works Laboratory of America, Inc.
Salt Lake City Lab
4525 South Wasatch Blvd., Suite 100, Salt Lake City, Utah 84124
Phone : 801.993.7124 Email: beastham@pewla.us.pewg.panasonic.com
Fax: 801.993.7260 Web: http://pewla.mew.com/index.php/User:Beastham
(Intranet only)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 29 04:51:45 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.