On Nov 28, 2006, at 7:51 PM, Bryant Eastham wrote:
> The difference is that we keep the bug information primarily in the
> 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
> 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.
I was presenting a simplified scenario for the discussion. Of course
I would not expect the final checkin to occur until after the bug had
been verified as fixed etc etc. My point remains, however: the
paucity of checkin metadata makes these kind of auditing workflows
difficult/impossible in Subversion.
I think you should contrast your "change the process" attitude with
the avowed philosophy of Subversion that the tool is supposed to be
You note that you do indeed add the bug number to the log message to
"justify" the checkin. To whom? A reviewer? I assert that a workflow
that relies on someone manually looking over the shoulders of every
checkin doesn't scale and doesn't seem very robust.
If I did indeed have a "BugID" revprop, then I could easily do the
1. Create a teeny-tiny helper script that:
(a) Did a commit with a revprop noting the bug number.
(b) Captured the rev# used for the commit.
(c) Marked in the defect database the rev# of the commit.
2. Then, I could also have a "lockdown" hook script that simply
(a) That the BugID revprop is present
(b) That Bug is open for checkin, and that the bug is assigned to the
user doing the checkin
This is a pretty normal lockdown workflow. Cleanly integrated into
Now, without such a revprop, I need to do all sorts of log message
parsing stunts. Yuck.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Nov 29 20:12:28 2006