Visual Studio integration

[Klaus Hartke]

John Arbash Meinel wrote: 
> I'm quite impressed that you've put together so much so quickly. Which
> route did you end up going? (High level embedding, or calling out to a
> bzr process).
>
[...]
>
> Are you planning on making any of this public? Have you thought 
> about hosting in on Launchpad? (https://launchpad.net).

This is just the prototype add-in I mentioned in my first post.
As described, it starts a new bzr.exe process for each operation.

Although I like the advantages of this solution (everything bzr-related
is already there -- I just have to create the dialogs and construct the
command-line argument for each operation), the drawbacks are just too
big, so I won't continue working on it.

Instead I'm thinking about starting again from scratch, this time using
embedded CPython at the core (thanks again to Alexander for coming up
with this), and turning my personal prototype into a proper project for
public release. Of course I'd be hosting it on Launchpad :)

I've got two ideas I'd like to hear your feedback on:

* My prototype currently just exposes the commands offered by bzr, e.g.
  'commit', 'revert', 'push', 'pull', etc. (making me make a visual dis-
  tinction between, say, 'pull' and 'update' quite difficult).

  Instead I'd like to support the user working with bzr's several dif-
  ferent kinds of workflow models like 'checkout-modify-commit-update'
  and 'branch-modify-commit-push-merge' (for example by hiding the
  unneeded options respectively).

* I'd love to have some kind of integrated issue tracking into Visual
  Studio, so you could create new work items from within the IDE and
  mark issues as being fixed when committing.

Has #1 been done somewhere before? Is it even possible to strictly
separate between these models, or do you end up using every command with
every model? (Most version control systems are focused on a single work-
flow model, so bzr's big strength of supporting several different models
may be quite confusing for new users.)

What do you think about #2? I guess this is what the bzr+trac project is
aiming for, except for the Visual Studio integration part. Does bzr+trac
provide some kind of interface for programmatical access?

Regards,
Klaus