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

[TSVN] Re: WebSVN and Issue Tracking

From: Tim Armes <timarmes_at_hotmail.com>
Date: 2004-08-25 10:41:44 CEST

Hello all,

The following request has been made to the WebSVN list, but I'm replying to
the TSVN list as well since it rather depends on your specification.

> The TortoiseSVN folks have been discussing integration of
> bug/issue tracking systems within Subversion. I am keen
> to see this implemented in WebSVN as well, or rather,
> the ability to hyperlink issues from within WebSVN based
> upon log and property data entered through Tortoise or
> other clients.
>
> A specification for this can be found here:
>
> http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt

I've searched the TSVN mailing lists, but I can't find any of the discussion
leading up to the document that you point to.

This specification seems rather incomplete. Read on...

> A suggested plan of attack for WebSVN implementation:

<snip>

> - If issueTracking property is set and `bugtraq:message`
> Subversion property has been set, then use `bugtraq:url`
> property in conjunction with `bugtraq:number` to create
> a hyperlink to the issue tracking system inside the log
> message.

I think that you've misunderstood here. The bugtraq:number (why do they have
to spell it with a 'q'? - I hate that) isn't the number of the issue in
question, it's simply a true/false property that states if the number should
be purely numeric or if it may include othe characters too.

Let's take an example. If the bugtraq:message property is defined to be
"Refer to bug number %BUGID% for more details" then the client will add the
line to the end of the log with %BUGID% replaced by the number input by the
user. This is all well and good, but bear in mind that there is no other
storage of the bug number itself other than this textual representation in
the message - it's certainly not stored in bugtraq:number nor any other
property. This is a real shame, that's the sort of thing that Subversion's
revision properties are good for.

Secondly, the specification falls shorts of describing the use of
bugtraq:url. Perhaps the author had in mind the idea that the bug number
being displayed in the log message would be clickable. That's to say, that
the '158' in "Refer to bug number158 for more details" would be a hyperlink.
Or maybe the author simply envisaged a button to open the bugtracker page?
He doesn't make it clear.

In the first case I suppose that this could be done by at commit time by
replacing %BUGID% with the appropriate HTML to the bug tracker. e.g. "Refer
to bug number %BUGID%
for more details". This is great for clients that interpret HTML. It's not
so great for WebSVN since it already interprets links. For other clients
seeing a load of HTML in the log isn't very useful either.

If the author had envisaged some other use of bugtraq:url then I don't see
what it would be, since the client would have no knowledge of the bug ID.
At a push the client could use it's knowlege of the bugtraq:message property
to parse the log message abd try to recover the number, but this would have
it's limits - what happens when the user changes the message string? It's
also a horrible hack

> Firstly, Tim, are you happy with this being implemented?

Once a coherent specification has been developped and implemented by at
least one write-access client (preferably TortoiseSVN) then I'm willing to
do the necessary.

The specification seems to be missing a few details.

* The bugtraq (please, can't we use English? IssueTrack for example - It's
not just bugs we commit, and traq isn't a word) value should be stored as a
revision property at commit time. By doing this the bugtraq:url can be
combined with the number at display time to form the link.

* The bugtraq:url is a versioned property. If the user want to change this
URL having, for example, moved the bugtracker to another server, then
previous revisions will still point to the old location. How should this be
dealt with? Of course this is exactly the behaviour desired if a new
bugtracker is introduced but the old bugs aren't migrated.

Regards,

Tim

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Aug 25 11:54:54 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.