During the last days, I implemented some basic integration of
TortoiseSVN with bug tracking tools. You might have noticed the
discussions about how to do that on the mailing list.
Now after discussing this and evaluating the possibilities, I wrote a
document on how TortoiseSVN now integrates with bug tracking tools. You
can find the document here:
http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
This doc defines how to set up your repository/working copy to integrate
it with your favourite bug tracking tool and how clients can/make use of
that. All what's written in there TortoiseSVN now does (in HEAD).
What's still missing are the modifications to our own docs, i.e. the
helpfile we ship with TortoiseSVN. (Martin, Lübbe: this is a hint for
you ;) ).
If other Subversion clients want to implement the same, please follow
the guidelines in the document mentioned above. Discussions are welcome
here on the list.
Stefan
P.S. Some proposals made in the previous discussions on the list are not
implemented/described in the document.
- a regexp expression to validate the bug id the user enters:
While evaluating how this could be done best, I found that there are
many regexp libraries available, but I also found that there is no
standard defined on how regular expressions should really work. The
perl regexp implementation is mostly used as a reference, but not by
all libraries I found. And some libraries even have special build
params to _not_ use that reference implementation but another one.
So that's one reason for not using them. Different clients could
use different libs and validate the expression differently.
Another reason is the size of those libs. They're really huge,
compared to what a Subversion client would need them for.
And last but not least: what would a client tell the user if the
regexp validation failed? Something like "your bug id does not match
the regexp string <some cryptic string here>!" - Most users don't
even know what regular expressions are, and most of those who know
wouldn't know what the expression string really does without looking
at a book first.
Most bug id's/issue numbers are just that: simple numbers. So a flag
indicating that only numbers are allowed is enough for almost all
bugtrackers out there.
- revision properties set for each commit:
Since revision properties can't be set with a commit, they would have
to be set _after_ the actual commit in a separate step by the client.
This would break the "atomic commits" Subversion uses. And what would
happen if the commit succeeds, but the revision property set fails? We
could end in an undefined state.
If a bug tracking tool needs to store those, they should do that in a
post-commit-hook on the repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Aug 21 20:36:10 2004