>> - 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
COM was created so that every language can *access* it. Not every
language can *implement* COM objects.
>> - 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?
OK. The issue-tracker integration would be implemented as a COM object.
Each repository might want to use a different issue-tracker. This means
that each repository (or working copy) might need to use a different COM
object for its issue tracker.
The obvious way to do this is to have a moniker (think URL, but for COM)
associated with the repository. This would identity the CLSID (or
ProgID) of the COM object, along with any other information required by
that COM object (e.g. database connection string, web service URL,
We may not want to have this information as a repo-prop, because the
owner of the repository might not be the same as the owner of the issue
> 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
The user story I'm attempting to solve here is this one:
1. Marvin the manager assigns a ticket or task to Dave, the developer,
using the issue-tracking or task-management software (we use
TargetProcess, I use Trac for my personal projects).
2. Dave looks at his list of tasks using the issue-tracking software's
front end (i.e. a web-dashboard). He picks something to work on this
3. Dave fires up Visual Studio; hacks on some code; does some work
toward the task.
4. Dave brings up TSVN's commit dialog. He types in a comment that lists:
a) The ticket/task number of what he's been working on.
b) Some comments about what he's changed.
c) How long he's spent working on the task.
d) How long he thinks is remaining.
5. He clicks OK, and his changes are committed to the repository.
6. TargetProcess monitors the SVN repository, watching for commits. It
sees Dave's commit message, extracts the information from it, and
updates the task, by adding "time" to it.
7. Marvin looks in TargetProcess, and can monitor the project's progress.
As it stands, TSVN supports (most of) this admirably. For example, with
the Trac integration, I can put "See #43" or "Fixes #99" somewhere in
the commit message, and Trac's post-commit hook will update the tickets
1. Dave has to keep the issue-tracker front-end open in order to look up
the ticket numbers.
2. Some issue trackers want more information (e.g. time spent, time
remaining), and it needs to be formatted more rigidly. For example,
TargetProcess wants something like (from memory): "task:66 spent:3
remaining:2 comment:Move strings to resource files"
So, the requirement is this:
From the TSVN commit dialog, the user should be able to display up a
list of assigned tickets from the issue-tracker associated with that
repository. The user should be able to pick one or more tasks from this
list. This will populate the commit message with the information
required by the issue-tracker's SVN server-side post-commit hook.
> 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.
But the script will block TSVN, because that information has to make it
back to the commit dialog. TortoiseProc has to wait for the information.
We can't simply use SendMessage, because:
1. It's not available from VBScript or JScript (but, then again, neither
is the ability to implement COM objects).
2. There might be more than one commit dialog open at the same time.
3. We can't just use the window handle, because the commit dialog might
have been closed by the time we come to post the message, and the window
handle might have been reused for something else (even another commit
At least if the COM object is in-process, it'll be running modal loops
in the same process, and the blocking won't be so painful.
I'll put together a demo project today/tomorrow to show you what I have
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:40:57 CEST