Re: Avoiding blocking the UI while running hook scripts?

Roger Lipscombe wrote:
> 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.

Ahem: COM was actually created so that *every* language can access it,
especially scripting languages like VBScript.
Have a look at the SubWCRevCOM subproject. And of course the example
javascript using it:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/SubWCRev/testCOM.js

> - we couldn't decide how to tie the CLSID (and extra information) to a
> particular repository, or to a particular working copy.

Not sure what you mean by this. What CLSID?

> 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.

I suggest that you first list the requirements exactly. For example,
what information should the script be able to return to the commit
dialog? And where/how would that information be used by the commit dialog?

As I see it, we only need some way for the script to return information
to the commit dialog, best inter-process. That way, the script could be
started as a separate process and wouldn't block TSVN or cause other
problems. Not sure if COM is the best way to do that though. If
SendMessage() would work for VBScript/Jscript, then I would go that way,
but I think it's not possible as you said.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net