[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

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...)


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.