Nick_Gianakas@sybari.com wrote:
> Where is the (or is there an) appropriate place to discuss the Integration
> with Bugtracking System (bugtraq) system?
> I think the idea originated here.
This is the right place.
[snip]
> 1. Add a new bugtraq: property to enable this mode of operation
> Perhaps "bugtraq:presentselectablelist" [true|false]
This isn't really necessary. A check for the property below would be
enough: if it's there, use it.
> 2. Add a new bugtraq: property to specify the name of the program/script
> to spawn.
> Perhaps "bugtraq:issuelistprovider"
> For maximum flexibility, the spawned entity could be an HTTP URL
> instead of a program/script. Supporting an HTTP URL eliminates the
> need for a locally-accessible program/script. It may also be easier
> to provide the issue list from a URL as many issue trackers have or
> support a web interface.
An URL would be enough. Most bugtrackers are web based anyway. And those
which aren't can install a new URL scheme to spawn the required application.
> 3. The SVN client will spawn the specified program/URL and provide
> certain input arguments (see "ISSUES" below).
> Input arguments to an HTTP URL can be in the form of
> GET/POST/other headers.
More than a normal "GET" would be too much. After all, we're talking
about Subversion clients here, not webbrowsers!
> 4. The spawned program/script will output a list of issues. For maximum
> flexibility, the output format should be XML. XML will provide
> flexibility in the client (parsing), and allow for differences in
> issue trackers (amount of info available/returned).
And here the problems start:
XML isn't something you can do without an external library. Even though
there are free XML libs available, they're all quite big - and
increasing the download size of a Subversion client by 150% just for
that is IMHO just too much!
> For example, the XML schema could define a full list of possible
> output, but perhaps the issue ID # is the only required piece.
> So if an issue tracker can return other info (project, component,
> subject, etc), it's up to client to display it.
You have to define _exactly_ what the client has to show. And don't make
this expandable - you'll just end up with a security risk (buffer
overflows, ...) if a client can't be absolutely sure on how the data has
to look like.
> See "SAMPLE XML FORMAT" below for a very simple/naive XML format.
> 5. Finally, when the output is received by the client, it can be parsed
> and presented to the user.
> It's important to note that the client can display as much or as
> little of the returned data as desired. For example: It can display
> only a list of issue numbers in a drop-down multi-select list box;
> It can display all available data in a full report list in a
> separate dialog; or it can display anything in betweeen.
Now what's the difference of spawning a separate dialog to just open a
webbrowser with a specific URL?
> ISSUES
> 1. Getting enough information to the input of the program that outputs
> the issue list so it can narrow down the list as much as possible.
> a) As a minimum, a user name should be presented. This migh
> require another bugtraq: property which will generate the
> issue tracker user name from the SVN user name plus some
> decorations.
> ex: bugtraq:issueusername %SVNUSERNAME%@mydomain.com
That's not possible: the username isn't known to the Subversion clients
until you commit. So where would you get that username from?
> b) Possibly some path information
What would that be good for? I mean every developer can have a different
path to his/her working copy. And not all of them will have checked out
from e.g. /trunk/ but maybe a subfolder, so even relative paths won't
help here.
> c) Possibly support other bugtraq: properties which can be
> fed as arguments.
> ex: bugtraq:issueproject, bugtraq:issuecomponent, etc
> d) Optionally support credentials for the issue tracker.
And that's exactly why this same feature request was rejected the last
time: you don't know where this should end. Everyone will have a
different request which would have to be added:
username/date/daterange/issuetracker-component/project/subproject/issuetype/...
IMHO this feature, as nice it may look, isn't something a simple
Subversion client ever should (or could) implement. That's what
webbrowsers are for. When this feature request first came up, we
discussed a simple text file which had a list of open issues in it,
separated by newlines. That's where it started: users wanted to reduce
the amount of issues presented to the user, so a daterange had to be
entered too, then a username to only get issues assigned to the user,
then came subprojects,...
To not throw away the whole feature, I suggested to just have a
button/link in the commit dialog which would open the webbrowser
pointing to the issue tracker. But that didn't help either: the URL can
have all the params in it as I mentioned above...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jan 10 18:49:04 2005