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

Re: [TSVN] Trac/bugtraq - Ticket to Changeset link [was: Re: Trac [was: TortoiseSVN 1.1.1 released]]

From: Lars Klose <lars.klose_at_klst.com>
Date: 2004-10-27 19:01:33 CEST

SteveKing wrote:

> Implementing this directly in Subversion won't happen.
> - Subversion uses DAV, not pure http. So it would need a separate lib to
> do that.
> - The bugtracking part is not tied to the repository, it is independent
> of that and therefore there's no 'direct' connection between them.

Ok, I wasn't as precise as needed here: I didn't mean _the_ svn client
but any (GUI) svn client based on it, just like TSVN, RapidSVN, xySVN.
I wonder what the correct terminus rather than 'that svn client' for
that would be... ;-)

> I think the URL is needed for one reason:
> there will be (believe me, there _will_ be) requests to add more
> information, and each user will want "just that information". To prevent
> changing the definitions and every client out there every two weeks the
> URL is needed. That way you can just tell: click on the link and you
> have the information there.

Sounds reasonable to me.

>> More fantasizing: If we had the URL on commit, it could even be stored
>> as a revision property. But: this would actually be a server side job
>> (through some hook) not the svn client's. BTW: That's what I was
>> trying with the ticket number lately - didn't have time to finish my
>> experiments though :-(
>>
>> Later on, if that revision property was in place, TSVN could provide
>> a link e.g. from that revision's log entry which opens the browser
>> with the ticket URL!
>
> Ok. Please, please read the document here:
> http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt

I did (twice, first time was some weeks ago though).
I probably overlooked this until now:

"When the user browses the log messages, there should be an easy way to
fire up the webbrowser to see the issue associated with that log
message/commit."

and how exactly it's supposed to be implemented.

Essentially, what I was trying to suggest is already there. I just
thought about another, slightly different (and maybe inferior)
implementation approach.
Sorry for that.... :-(

Read on if you've still got the nerve - otherwise just skip the rest...

What I don't understand is why it would be a "bad thing" to skip the
parsing part and simply get the issue number from a specific revision
property which is set on the server side (through a hook script which
does just the same parsing that TSVN would do on demand - but only once).

Am I missing something?? (Sorry if I'm being annoying...)

Lars.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Oct 27 20:07:47 2004

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.