>> 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?
Now that's not silly. I don't believe that I have heard anyone say the rev
props are inherently bad. Currently there isn't a way to set them at commit
time. Since they aren't versioned allowing them to change means information
can be lost. The philosophy of the subversion team is that nothing should
ever get lost. There is nothing stopping you from enabling them except for a
semi-trivial hook script. There could be other dangers of which I am not
aware. The point is that there are 2 choices:
1. Subversion makes no assumptions about repository layout or how it will be
used. This allows subversion to support many different methodologies.
HOWEVER, this means that the end user has to do most of the work required to
ensure that the processes that accompany the methodology are carried out
correctly.
2. Subversion enforces specific methodologies. This is less work for the end
user as certain conventions and processes are already enforced by the
software. This is great as long as your methodology matches what the
developers decide on.
For better or worse the subversion project appears to have adopted the
first. I think it works pretty well. There are certainly things missing.
Since we aren't paying any of the developers they get to decide what's most
important. Currently they are working on true renames and merge tracking
(among other things.) Both of these seem more important to me than labels.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 29 00:43:13 2006