Roger Lipscombe wrote:
> (Bah. Posting this from my other email address, because I can't figure
> out how to get Outlook 2007 to quote properly)
Nobody ever figured that out :)
> 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
> seemed appropriate.
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.
Something like
<issuelist>
<issue>
<content>this would be some text of the issue</content>
<assignee>username</assignee>
<id>1234</id>
<...>
</issue>
</issuelist>
>> 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.
Seems like a good idea! In case you store the credentials, you would
also have to provide the means to clear those if needed.
> 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.
> 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.
Great. Examples are always good as a starting point for people who like
to do the same for other issue trackers.
> 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.
Once you start with an open source project you will soon learn that what
you had in mind isn't exactly what people expect :)
And often, you'll get a whole lot of ideas on how people would like a
certain feature to work. If you've never worked on an open source
project, I can promise you that you'll be surprised :)
>> 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.
I think we can assume that issue trackers are web based or at least
accessible through some other means using TCP/IP. Which means the
background thread is necessary.
>> 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
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
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-02 16:19:21 CET