Tim Armes wrote:
> 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?
Uh-oh. No, sorry. We had some discussions with several people involved
in both open-source and commercial bug tracking tools and we came to the
conclusion that this is the job of the bug tracking tools. Since TSVN is
a client and hooks are done on the server, this was well accepted. And
honestly: I wouldn't know how to do it - I only know C/C++ and some
java, but no perl, PHP, python or any other scripting language which is
usually used to write such hooks.
> 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.
Good point. I'll add some description on how it is intended to be used.
But not as a "definition", just a hint on how clients could use it. I
don't want to define this because every client might implement this
differently to suit its own GUI.
> 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?
Both. Bug tracking tools will parse the log message in a hook. That's
why the 'message' property is there: that way both the hooks and the
clients _know_ the format and can parse the log message for the defined
pattern.
> 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.
The issue tracker parses the log message to get the bug ID for the
commit. Once it has the ID, they can set a revision property (if they
want to) and use the ID in their tracker. With that ID, they can provide
the users with a list of revisions which are assigned to a specific
issue. So the issue-view would then have such a revision list. That's
why the issue trackers need to parse the log message. Apparently, most
of them already have such a feature implemented for e.g. CVS commits,
but as they all told me the parsing is a real nightmare since users
don't have a defined pattern on how to write "parseable" log messages.
That's when we came up with the 'message' property to define such a
pattern. The client then hides that pattern from the user by simply
providing a text box where the user only has to enter the bug ID and
doesn't have to know the pattern.
And the clients then can parse the log messages the same way as the bug
tracking tools do to provide the user with a link to the issue, creating
the link from the additional 'url' property.
> So if I understand:
>
> * TSVN reads the log message and the bugtraq:message string defined in the
> working copy (often HEAD, but not always)
correct.
> * TSVN then tried to locate the issue number by searching the log message
> for the string defined by bugtraq:message and parsing as appropriate.
correct.
> * TSVN replaces the issue number with a hyperlink based upon bugtraq:url
correct.
> Where does the revision property you mention come in?
The revision property isn't for the client. And it's also nowhere
mentioned in the document because of that. It was mentioned in our
discussions with the bug tracking tool people (I have to admit that a
lot of those discussions were made outside of the mailing list because
they didn't wanted to subscribe yet to another list). The revision
property would only be used by issue trackers to link a specific
revision to an issue.
> 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?
I would suggest that WebSVN looks for those properties in HEAD. Also,
WebSVN isn't a bug tracker, so the revision property is of no real use
for you. I suggest that you simply parse the log messages and then make
a link from it.
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 14:14:58 2004