>
> Except for the "it's too hard" arguments listed above, I still do not
> understand how a tag is not a label. Oh yeah, you have to install a
> hook
> script to keep people from turning them into branches...
>
> Of course then you have to use conventions. But the software
> shouldn't force
> any conventions on me but it should know what a tag is but I should
> have to
> tell it what a tag is but I should be able to do things however I
> want but I
> shouldn't have to setup the software to do what I want it should
> just work
> out of the box...
>
> I don't mean to be offensive but some of this thread just seems
> silly to me.
> Someday will have software complex enough to figure out what I
> meant to do.
> Until then I am going to have to be explicite.
>
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?
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 28 23:37:30 2006