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

Re: Simple Label=RevisionID Discussion

From: Gerco Ballintijn <gerco_at_ballintijn.com>
Date: 2006-11-29 12:30:01 CET

L. Wayne Johnson 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?
>
> 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.
>

But the notion of not changing revision properties is downright silly.
It is a basic fact of life that people make mistakes and that these
mistakes have to be corrected. If one follows the commit messages of
Subversion itself, one sees an endless stream of corrections on commit
messages. I cannot imagine it going any other way.

The main problem with revision properties *changes*, is the current
lack of an *internal audit trail* of revision property changes (the
currently suggested remedy is sending an email). Otherwise, allowing
changes, possibly by specific people, is a policy matter, best left
in the pre-revprop-change hook.

The other problem with revision properties, as indicated by Tim Hill,
is that they cannot be set at revision creation time. Solving this
problem would make them significantly easier to use, and thus more
useful.

With regards,
Gerco.

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