[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue Tracker Integration

From: Roger Lipscombe <roger_at_differentpla.net>
Date: Wed, 02 Jan 2008 16:12:25 +0000

Stefan Küng wrote:
> The idea was that we could define some xml schema which the various
> issue trackers then would have to implement/provide. But I guess apart
> form the open source trackers, others wouldn't implement this anyway.
>
OK. I see what you mean. This doesn't work so well if the issuetracker
plugin wants to be able to create new issues on the fly, which is
something else on our internal wishlist.
>> Worst case (I guess) the COM object would have to prompt for (and
>> potentially cache) the credentials. This would be on per-repos basis,
>> so this would have to be one of the parameters to the COM interface.
>
> Seems like a good idea! In case you store the credentials, you would
> also have to provide the means to clear those if needed.
>
This part might be best implemented as a hook into the "TortoiseSVN
Settings" dialog. This means that TortoiseSVN would have to know about
all available issuetracker plugins. This could be done by COM
Categories, or something else.

This raises the possibility that each plugin could be asked whether they
care about the repos about to be committed.

This goes some way to addressing another concern that just occurred to
me: that of the issue tracker being totally unrelated to the repos
(which might happen). Consider someone using Launchpad as their bug
tracker, but committing to the Debian repository. The Debian folks
shouldn't have to set the "bugtraq" properties for this. OK, not a great
example, but I hope you see what I mean.

On the other hand, this kind of connection is implicit in the
bugtraq:url property, so maybe I'm worrying unduly.

>> If implemented the way I imagine, this is a problem (an
>> implementation detail, rather than an interface detail) for the COM
>> object to handle, rather than for TortoiseSVN.
>
> Sure, but it should work anyway, not matter where the responsibility
> lies.
>
Totally agree, but it's more a recommendation guideline for implementers
of the COM interface, rather than something that needs to be addressed
in TortoiseProc itself. That is: it's a documentation issue (and one
which can be addressed in any example implementations). Or do you see it
differently?

>>> That would be great. But before you start coding, please send us
>>> your ideas on how the COM-Interface should look like and how you
>>> want to proceed (once you've made yourself familiar with the code a
>>> little bit). It's an open source project after all, and we like to
>>> comment early on for big tasks.
>> OK. I'll get TortoiseProc built and spike something out in the next
>> week. That'll give me an idea of direction, and then I can write some
>> slightly more formal documentation for my proposal.
>
> Great. Waiting to hear from you.
>
> Stefan
>
Roger.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-01-04 04:56:56 CET

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.