Stefan Küng wrote:
> Roger Lipscombe wrote:
>
>>> Maybe registering a window message which the script can send back to
>>> the commit dialog with info once its finished could help. Such
>>> messages can be sent even by other processes, so it would be
>>> possible to start the script as a different process - that way the
>>> commit dialog doesn't have to care about a thread still running.
>>>
>> This won't work for hook scripts that can't send registered window
>> messages (e.g. VBScript).
>>
>> The background thread thing is a relatively easy fix: in RunScript,
>> where we're waiting for the process to exit, simply add another
>> handle, hAbandon. Closing the 'wait' dialog sets this handle and
>> waits for the thread to finish. This will let the process continue to
>> run happily; we just won't care about it. OK, the output is still
>> redirected to temporary files, which we won't have a chance to clean
>> up, but we could redirect to pipes instead.
>>
>> Alternatively, if you do want to use registered window messages, we
>> could spawn another instance of TortoiseProc to host the hook script,
>> and it could post the messages back. I'd prefer a different
>> TortoiseHookRunner.exe, but that complicates the
>> build/package/installation story.
>>
>> Let me know your thoughts and then I'll press on with an
>> implementation...
>
> I think this now gets way too complicated. We should instead implement
> a COM interface which the scripts can call to send data back.
>
I think we're going around in circles a little here. Let's recap, and
see if we can't clear this up a bit:
It'd be a useful addition to TSVN if it was possible to query an
external issue-tracking system, and to have information added to the
message for a particular commit. For example, the user would choose an
issue or task from the list of those assigned to her, and the text
"Closes #42" or "See #56" was added to the commit message.
This message would typically be picked up by the server's post-commit
hook (or by some other filter), and would be used to update the
issue-tracking system. For example, it might close a bug, or it might
add time-spent statistics to an outstanding task.
Initially, we discussed adding a button or hyperlink to the commit
dialog. This would create a COM object which would talk to the
issue-tracking system. This has the following pros and cons:
+ it would run in-proc, making it easy to enforce dialog lifetime semantics
- restricted to languages that support implementing COM objects (e.g.
C++ or C#); it wouldn't be possible to write this in VBScript.
- we couldn't decide how to tie the CLSID (and extra information) to a
particular repository, or to a particular working copy.
Fortunately, TortoiseSVN 1.5 added client-side hook scripts, which gives
us a little more latitude. We discussed having the issue-tracker hook
run before the commit dialog was displayed -- you'd pick an issue from
the list, and the commit dialog would be pre-populated with this
information. This has the following pros and cons:
+ no redraw problems -- at this point TortoiseProc hasn't brought up any
dialogs, so it's no problem to block on the hook process.
+ not restricted in implementation language.
- You can't see the list of changed files before you choose an issue
from the list (without replicating a bunch of TSVN functionality,
anyway). This was a deal-breaker for us.
So, we decided that I should implement it as a client-side hook
triggered by a button in the commit dialog. This has the following pros
and cons:
+ Simple implementation: I think I had to touch about 10 lines of code
to get it in there.
+ not restricted in implementation language.
- because the commit dialog has to stay open until the hook process
finishes, we get redraw problems.
We're arguing about this last point.
It strikes me that:
a) A client-side hook script wasn't the right way to implement this
functionality. Yeah, it was simple to do, but semantically, issue
tracker integration is different from the other hooks -- it's
interactive. This is painfully obvious when you look and see that the
"Wait" checkbox in the hook configuration dialog is ignored for this
hook. One of these hooks is not like the other hooks, as the cookie
monster might say.
b) Who cares that you can't implement them in other languages? Someone
could implement a shim which spawns an external process.
So, I'm proposing that I do the following:
1. Investigate how to associate a working copy or repository with a
particular COM object and initialisation information.
2. Take out the issue-tracker hook code. It was only ten lines or so of
changes, so it'll be easy to remove.
3. Implement it properly.
4. Provide example implementations in both C++ and C#.
This has the following advantages:
a) it's semantically clean -- the functionality's not just wedged in
somewhere that it doesn't quite fit.
b) it'll avoid the redraw problems, because the COM object will be
running on the same thread, using a standard modal loop.
Regards,
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-04-22 08:01:37 CEST