Re: Patch for bzr support in Meld

[Aaron Bentley <aaron bentley utoronto ca>]

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

(I'm not subscribed to the list-- please cc me)

Stephen Kennedy wrote:
| With regard to licencing I suppose the vc plugins could be individually
| licenced if that makes it easier.

I can understand your motivation for bsd-licensing it, too.  Anyhow, we
can revisit it later if we want to go native.


~ One thing which may be problematic
| about using the python interface is that meld is inherently single
| threaded and should not block or call long-running functions. Reading
| from pipes is ok since we can use callbacks with nonblocking reads
| when they become readable.

Ah, I see.  There has been some discussion of supporting async operation
(via twisted) in bzrlib.

| On that note, perhaps it would make sense for the vc library to become
| a standalone vc executable which reads commands from stdin and
| produces output in a standard way. (similar to bzr status and hg status)
| Then each plugin could be licenced individually.

As long as it was a long-running process, i.e. a server, I think that
could work pretty well.

| I'd prefer not to have the vc plugins modify the tree directly as in
| _search_recursively_iter because I'm going to replace the tree
| model at some stage. I'd like to draw a clear line between meld and its
| plugins. The current interface is basically a dry run, so now is a great
| time to suss it out.

Sure.  So for some VCSes, a model which allowed us to return the status
of the entire tree at once would be the most direct and performant.

| The patch looks good : I've applied the patch with only a minor
| change to give cache_inventory a hint as to the top directory.

Excellent.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDaSCR0F+nu1YWqI0RAgJ/AJ0YB3uvm1/a4liL701/g8hqNObOXwCfftbo
X+pQlr+ivm4v5vXLAk1KjBU=
=sXFY
-----END PGP SIGNATURE-----