Mark Phippard wrote:
>> You're right, there's no way to answer the question "which revisions
>> reference issue 123". But issuetrackers which have direct access to the
>> repository can modifiy or read revision properties much easier than log
>> messages (no need to parse them).
>
> True. I suspect most have gone the hook script route though, where
> they store this in the issue tracker. The performance wouldn't scale
> to get it from SVN.
I don't know about the performance, but I suspect it would be slightly
faster to just read a property than to read a (maybe) long log message
and parse it.
>>> On the plus side, it makes things easier for people writing hook
>>> scripts that want this information.
>> And don't forget: the log message itself won't have to be modified (it
>> still can be, of course).
>
> Do you mean if the issue needs to be changed/added? I see this as a
> downside if the two become out of synch. This is kind of what I am
> getting at by doing users a favor by not supporting this.
Haven't thought of that. Yes, that would be very bad. And revision
properties aren't even versioned. :(
>>> Having used the feature now for so long, the log messages feels like
>>> it is the right solution. Especially since command line users and
>>> clients that do not implement the feature can so easily participate.
>>> I think when you introduced the regex stuff, it really solidified that
>>> the log message was the right way to do this.
>>>
>>> I think we might be doing users a favor by not supporting an option like this.
>> How about not making it an option but simply always set that property?
>> That way, there's no need for additional configuration for the user, but
>> the revision property will always be there and can be used by those who
>> need it.
>> It shouldn't be too much work to implement this: we already know the
>> issue IDs from the log message the user entered, and adding the revision
>> property to the ctx structure before commits should be easy enough.
>
> I'll ultimately do my best to support what you decide. Subclipse
> might not get this until 1.6 though as none of these API's are exposed
> via JavaHL and I think the clock has pretty much run out on getting
> some of this (in terms of JavaHL). I think that is OK though, as you
> have often had features ahead of us for a release.
Well, I don't like to just decide about features that affect other
clients as well. That's why we have this discussion ;)
But are you sure about the API's not being available in JavaHL? The
setting of revision properties is done by filling a hash table in the
client context struct which you must pass anyway (the hash table is set
to NULL if it's not used, which is the default).
I guess we should postpone this feature until someone comes up with a
very good use for it.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Oct 12 23:34:50 2007