On Nov 28, 2006, at 22:05, Tim Hill wrote:
>>> Or, what I want is this:
>>>
>>> svn commit ... --revprop "BugID=2788"
>>>
>>> What's so silly about that?
>>
>> 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.
>
> As I've noted repeatedly, this speaks to a hole in the Subversion
> revprop model. The logic seems to go something like this:
>
> Changes to an existing revision are bad.
> Revprops change an existing revision.
> Therefore, revprops are bad.
>
> However, this is faulty logic; revprops only change an existing
> revision when applied retroactively. There is thus a fundamental
> difference between a revprop applied at commit time (harmless) and
> a revprop applied retroactively (potentially dangerous); this
> distinction is not made in the existing command set nor in the hook
> scripts. This means that I cannot realize my defect tracking
> scenario without also exposing existing revisions to potential
> mutation. No amount of script wrapping or hooking can overcome this.
I believe that's easy to achieve with hook scripts: write a pre-
revprop-change hook which accepts additions of new properties, but
rejects modifications to existing properties.
If I'm not mistaken, there is existing Bugzilla integration which
uses a revprop to hold the bug ID. I believe TortoiseSVN also plays
along with this model and provides a way to enter that information at
commit time.
--
To reply to the mailing list, use your mailer's Reply To All function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 29 06:59:05 2006