Hello,
> 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.
Ah, a good point. Surely though you have to commit before setting the
revision property? Will you be supplying example hook scripts that do this?
> > Secondly, the specification falls shorts of describing the use of
> > bugtraq:url.
> And why should that be made clear? It's up to the Subversion client on
> how they want to use that feature.
Well it would be nice if the document explained at least how the bugtraq:url
property might be used. I couldn't understand at what point it would be
useful given the lack of issue number. The document makes no mention of
hook scripts or log message parsing in order to recover the number.
> 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.
So are you advocating the use of a revision propery controlled by the hook
script or the parsing of the log file by the client?
> > At a push the client could use it's knowlege of the bugtraq:message
property
> > to parse the log message and 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.
Now I'm really getting lost. Why does the issue tracker (why are we using
'bug'?) have to parse the log message? Isn't the objective of this change
to allow the user to go directly to the bug from the Subversion client?
What am I missing.
> > 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.
So if I understand:
* TSVN reads the log message and the bugtraq:message string defined in the
working copy (often HEAD, but not always)
* TSVN then tried to locate the issue number by searching the log message
for the string defined by bugtraq:message and parsing as appropriate.
* TSVN replaces the issue number with a hyperlink based upon bugtraq:url
Where does the revision property you mention come in?
How would you propose that a client such as WebSVN handles the situation?
Should I always look at HEAD for the properties or should I look at the
properties defined by the revision under inspection?
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 13:44:59 2004