Tim Armes wrote:
[snip]
>>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.
http://news.gmane.org/gmane.comp.version-control.subversion.tortoisesvn.devel
and look for "integration with bugtracking tools".
> 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
The reason for why: it isn't spelled correctly so that the chance of
breaking someones private and already set properties don't interfere
with the new defined ones.
> 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.
Not just purley numeric! Commas are allowed too so that several issue
numbers can be entered.
> 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.
Setting the revision property is not the job of a Subversion client. A
client _can't_ commit and set the revision property in one atomic
commit. But a pre-commit-hook can first parse the log message, set the
revision property and then allow the actual commit - that way, atomicity
is guaranteed. So the setting of the revision property is the job of a
pre-commit-hook.
> 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.
And why should that be made clear? It's up to the Subversion client on
how they want to use that feature. Some might provide a link from the
log message view, some might provide a button for that, and others may
even use it in some magical other way I couldn't think of yet.
> 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.
And that's why it should be done that way! That's why there are _two_
different properties: url and message. The message part is the one for
the log message which should be something a pre-commit-hook can use for
parsing, and it should be user readable too (because it gets added to
the log message). So no html, xml or other non-readable things there.
To have a link use the bugtraq:url property. That's why this property is
defined separately: to keep the log message clear. If you want to
provide a link, parse the log message and create a link online.
> 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.
The bug ID is in the log message. The client can parse that.
> 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
When the user changes the string, then the bugtracking tool wouldn't be
able to parse the log messages anymore either. So just tell the user to
_not_ change the message and only use the one defined by his bug
tracking tool.
> 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.
TortoiseSVN has it implemented in HEAD.
> 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.
As mentioned before: it's not the job of the client to set the revision
property but the job of the pre-commit-hook.
And: revision properties always require a client to contact the
repository to read them. Over a slow connection, this would render a
client UI horribly slow. (Not an issue for WebSVN since it has direct
access to the repository, but clients usually don't have that).
> * 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.
Since this definitions is for clients:
- a client reads those properties from the working copy, _not_ the
repository. And therefore usually (in really, almost all cases) uses the
properties set in HEAD.
- Subversion doesn't provide repository wide config files or revision
properties stored in the working copy or something like that. So we have
to use what's available.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Aug 25 12:35:01 2004