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

Re: Enhancement for the issue tracker integration

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-10-12 23:34:32 CEST

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

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.