Re: Issue Tracker Integration

On Feb 3, 2008 2:53 AM, Roger Lipscombe <roger_at_differentpla.net> wrote:
> Stefan Küng wrote:
> > Roger Lipscombe wrote:
> > How about implementing a custom window message which the script could
> > send, containing the modified text?
> >
> > That way, TSVN could simply start the script and go on. The script
> > once it has the information it needs could then send the message back
> > to the TSVN commit dialog.

Actually, I do not see a hard reason for blocking.
TSVN basically just does a busy-loop in CHooks::RunScript, catching
redirected STDERR into a string. Surely, the code is simpler this way,
but what prevents it from waiting in a separate thread?
Especially if Roger will implement it ;-)

> The problem with allowing TSVN to carry on is that the user could then
> enter something else in the box, which we'd end up overwriting later:
> classic race condition.
[skip]
> Obviously, because the hook's blocking the UI thread, there'll be redraw
> problems.
>
> I think that, in order to preserve the expected UI behaviour (i.e. so
> that it looks like any dialog brought up by the hook is modally nested
> inside TSVN), we'll need to disable the dialog and wait for the hook in
> a separate thread. Granted, it's not going to be asynchronous, but I
> think it's the simplest way to do this. I'll think about this some more.

I agree with both th reasoning and proposed implementation.
Additionally, an option to kill running script from 'waiting'
TSVN interface would be good.

> >> 2. How best to allow configuration of the text on the button that's
> >> added to the Commit dialog.
> >
> > Is that necessary?
> >
> Well, it currently says "Bug Tracker...". Some people (a previous boss
> springs to mind) don't like the word "bug". They prefer the word
> "issue". I guess it can stay as it is for now.
For the purpose of issue tracking integration I agree that current name
is enough. However, the mechanism is in fact more general than that --
it can compose/modify commit message in any way, not necessarily based on
some 'issues'.
For example, I can imagine a script to collect file and function names
from the diff
and format them per Subversion log message guidelines
(http://subversion.tigris.org/hacking.html#log-messages).
For such a script "Bug Tracker..." button name would be clearly wrong.
How about
1) renaming a hook to e.g. "compose massage hook"
2) renaming a button -- not sure how, perhaps just "Compose..." or
"Auto-compose..." ?

-- 
Alexander S. Klenin
Insight Experts Ltd.