Visual Studio integration

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Klaus Hartke wrote:
> Hey guys,
> 
> I recently discovered Bazaar as alternative to SVN for use in my final
> year project (still need to convince my fellow students though) and
> started working on a prototype add-in for Visual Studio 2005 (since we
> are going to develop both under Windows and Linux, and the latter seems
> already well supported in the form of Olive).
> 
> While scanning through the mailing list archives I noticed Bazaar is
> taking part in this year's Google Summer of Code, so I started thinking
> about turning my prototype into a real project. I found a few options
> how to interface with Bazaar:
> 
> (1) Wrapping bzr.exe by redirecting stdout and stderr
> 
>      This is how the prototype is doing it at the moment. Allows very
>      fast development, almost all major commands are already supported.
>      Problems:
> 
>       - It is impossible to detect when interactive input is required
>         (e.g., when logging in with SSH)
>       - stdout and stderr are redirected through a pipe which buffers
>         all output until the process terminates (so no fancy progress
>         bars here)
>       - It is impossible to cancel any operation except by killing the
>         process (you cannot send signals/KeyboardInterrupts through
>         stdin)
>       - In future releases bzr.exe may change its output format.

There are some options here. One is if you get the latest bzr, it should
have support for using Putty's 'plink' as its ssh program. And I think
plink can be configured to pop up a dialog for interaction.

There are some other possibilities, too. Our python ssh and sftp library
(paramiko) has direct support for pageant (putty's ssh agent). It would
be pretty easy to write a plugin which derives from

bzrlib.transport.ssh.ParamikoVendor and implements a custom auth
command. Or even just monkey patches bzrlib.transport.ssh._paramiko_auth
to use a Win32 dialog.

The only other interactive command is "bzr uncommit", which

1) Probably isn't supported by the standard VCS integration. As CVS/SVN
don't really have 'uncommit'.

2) You can supply --force, and it won't prompt.


> 
> (2) Using IronPython
> 
>      IronPython is a .NET implementation of a Python interpreter and
>      compiler. Would bring VAST speed improvements and would run both
>      on Linux (and any other supported platform) with Mono, as well as
>      on Windows with Microsoft's .NET, -- opening the gates for easy
>      Bazaar integration into (for example) MonoDevelop and the Windows
>      explorer.
> 
>      However, IronPython (unlike CPython) does not come with batteries
>      included, i.e., the CPython standard library is not very well
>      supported yet, and calls into C-code are not supported at all.

This is my favorite idea, as the bzrlib api is quite rich versus what
you can get from a command line.

There are a couple limitations that I'm aware of with IronPython.

1) Last I tried it wasn't python2.4 compatible. But I thought I've read
about updates to 2.4 compatibility. This is one of the bigger hurdles,
as we use decorators and generator comprehensions in our code.

2) Lack of common modules like "sha".  I don't know specifically which
modules IronPython is missing, but running the test suite would probably
point them out. Hopefully some of them would be easy to update.

3) At this moment, we make very few calls directly to C functions. The
only ones I'm aware of are the Win32 api LockFileEx. Which I would hope
is exposed by IronPython in some form. Again, this should be as simple
as implementing another Lock type, and inserting it as the default lock
implementation.

  Selecting the implementation is new as of today, though, so I wouldn't
expect you to know you could do that. :)

> 
> (3) Talking to the smart-server directly
> 
>      This was suggested in an old post to this list some time ago.
>      How much would a 'dumb' client require? Does it make sense to have
>      a local smart server running just for local branches?

At this point, the "smart server" isn't terribly smart. So you would
have to implement most of 'bzrlib' to do anything. In the next month or
two, I expect the smart server to get a lot smarter. (Andrew Bennetts
has been doing good work on his 'hpss' branch).

So this may become more of an option. At the moment, though, the smart
server is more focussed on network and repository/branch operations, not
on working tree operations. (stuff like give me X revisions, but not
stuff like "update my working tree".)

However, the smart server should be extensible, so again it might make
sense to write a plugin to provide a set of working-tree access commands.

> 
> (4) Implementing it with CPython to access bzrlib directly
> 
>      Unfortunately Visual Studio requires add-ins to be written a .NET
>      language.
> 
> I saw a TortoiseSVN-like application being mentioned somewhere, and
> there is Guillermo's Eclipse Plugin for Bazaar (or Bazaar Plugin for
> Eclipse). What approach(es) are you taking here?

My understanding is TortoiseBzr will use pywin32 and win32com to
register and communicate with Explorer. This is still at a pretty basic
level (can we do this??).

But if it goes somewhere, it certainly ends up giving you a way to talk
COM to a running bzr process.

I think the Eclipse plugin is trying to use bzr as a command line tool.
(Similar to how Eclipse would talk to cvs or svn, afaik). Getting bzr to
run on Jython would be nice, but again you have python 2.3/2.4
compatibility and a limited standard library.

> 
> Are there more ways to interface with bzr?
> 
> Would implementing one of these options (#2 or #3) make a viable GSoC
> project? My general aim would be a platform-independent library written
> in C# and/or IronPython, plus Bazaar integration into Visual Studio.

I would hate to see you re-implement bzrlib in C#. I'm guessing it would
be easier to get the few standard library functions that we need. (You
could implement sha in python as a "slow but functional" sort of step)

> 
> I'm not sure if I should make my prototype publicly available in its
> current state, as it's really just a prototype and the installation
> process would be rather painful. But if anyone is curious about it,
> I'd be happy to give a walk-through :)
> 
> Regards,
> Klaus

You can't get feedback on something people can't see. :)

But certainly feel free to ask questions here or on IRC
(chat.freenode.net, channel #bzr).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+aHGJdeBCYSNAAMRAqwIAKCbd4/TiQ4YQTNtEDYZ9YD9vuXhTgCgkARt
ytvcHkjxHVXhvAPimR07pCs=
=1Xbu
-----END PGP SIGNATURE-----