(Bah. Posting this from my other email address, because I can't figure
out how to get Outlook 2007 to quote properly)
Stefan Küng wrote:
> Yes, you have to implement this in TortoiseProc.
Cool. Glad to know I'm not completely off the mark from the beginning :)
> Previous requests like this suggested that the issuetracker itself
> would provide all the open/assigned issues as an xml file which TSVN
> should then parse and show to the user. But of course, using COM isn't
> a bad idea.
Could you point me at (or explain) this concept? I had a search through
the mailing list before I posted this, but I didn't find anything that
>> The COM object would be associated with the project by having a new
>> “bugtraq:clsid” or “bugtraq:clsid” property, in the same way as you
>> might use the “bugtraq:url” property. It would be passed the other
>> bugtraq properties (or even all of the properties, including
>> “inherited” ones). There would hopefully be enough information in
>> these to identify the project in the issue tracker.
(Er, that should read "bugtraq:clsid" or "bugtraq:progid"...)
> One problem you have to consider: how would you know the *user* to ask
> the issues for? Because the username for the commit is not known at
> that stage of the commit operation.
Hmmm. In our situation, that's not a problem, because we use SSPI. I can
use either the currently logged-in user, or I can rely on integrated
NTLM auth with the issue tracker to give me the correct issues. 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.
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.
My plan was to define the COM interface and requirements, implement the
client-side stuff in TortoiseProc, and leave the rest as an "exercise
for the reader". I might do an example implementation against Trac (once
the XmlRpc plugin is brought up-to-date with Trac-v0.11, probably).
We're not going to be using Trac at work, but I've started using it on
some personal projects.
My plan was to implement something useful to us internally, but generic
enough that the patches could go back into TortoiseSVN core, to save us
the overhead of building TortoiseSVN every time you guys drop a new
release. Hence COM.
> Your idea is good. But I guess you'll soon discover some problems
> (like not knowing the username beforehand).
Thanks. I'm not so sure that the username thing is as big a problem as
you make out.
That's probably because I'm a little blinkered by only ever using
Subversion and TortoiseSVN on closed-source stuff, and not having to
think about the open-source side. I'd definitely appreciate any insight
you could offer into how this feature would be used differently.
> Also you have to make sure that if the issuetracker is not responding
> for whatever reason that the user still can cancel the dialog or go on
> with the commit.
Yeah. This depends on the API to the issuetracker. If it's a web service
(e.g. XML RPC or SOAP), then I can run the call in a background thread
and cancel it if it's taking too long. If it's something else, this
needs more thought.
> 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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jan 2 15:58:40 2008