[ANN][PLUGIN] extending diff with graphical tools

[John Arbash Meinel]

Stephen Ward wrote:
> Hi,
> 
> I've extended my 'bzr_kompare' plugin to support multiple graphical diff 
> tools, and reworked it to extend the 'bzr diff' command instead of adding a 
> new command for each tool.  The new and improved plugin has been renamed to 
> 'bzr_difftools', and can be downloaded as either a bzr branch or a tarball 
> from:
> 
>    http://mysite.verizon.net/sward.dev/projects/bzr_difftools
>    http://mysite.verizon.net/sward.dev/projects/bzr_difftools.tar.gz
>    http://mysite.verizon.net/sward.dev/projects/bzr_difftools.tar.bz2
> 
> I've update the plugin registry accordingly.
> 
> With this extension, the 'bzr diff' command now supports a '--using TOOL' 
> option, like:
> 
>    bzr diff --using kdiff3 [FILES...]
> 
> I've tested it with fldiff, kdiff3, kompare, meld, vimdiff, and xxdiff.  Most 
> diff tools will run without any need for customization; for the rare cases 
> where additional options are needed, they can be added like this:
> 
>    register_diff_tool(DiffTool('xxdiff', diff_options='--exclude=.bzr*'))
> 
> and more complicated customizations can be made by sub-classing DiffTool.
> 

What about "gvimdiff -f"? (Or gvim -d -f / vim -d). I prefer to use vim
-d to "vimdiff" because at least on my Mac, there is no vimdiff after
installing Vim.
gvim (graphical vim), versus vim -g, since most of my experience says
that vim is frequently not compiled in graphical mode. (It requires
connecting to X even for non-X mode, which is really slow over a remote
connection).


> 
> Possible future work:
> 
> * integrating this into the bzrlib core, as Martin suggested.  I  chose the 
> plugin approach for now because of the 0.8 feature freeze.

A plugin is a good way to play around with it. But we should definitely
review bringing it into core after 0.8.

> 
> * extending this to 3-way diffs, which most of these tools support.  However, 
> this does not fit well with 'bzr diff' usage, so perhaps it would be better 
> to ...
> 
> * extend this to 'bzr merge', possibly combine with the 'extmerge' plugin

I definitely think we will want something for 'bzr merge'. One thing you
might consider is what options will be needed for "DiffTool" to support
merge operations.
Maybe just a field for "supports_merge=True", or something like that.

I think it also might be useful to have a merge operator where you could
do: "bzr merge --merge-type=merge3+gvim"
So that bzr can try to do a regular merge3, and if there are conflicts
it could spawn gvim to resolve them.

I would probably use it more as "bzr merge" which reports some
conflicts, and then "bzr remerge --merge-type=gvim file/foo".

Though I know I would prefer a more streamlined workflow overall. Right
now I do a merge, see the list of conflicts, and then edit the first
one, and resolve it. Then the second... Then I type 'bzr conflicts'
again because the list has scrolled out of site, and keep repeating it.

It would be nice if I could spawn an editor for each conflicted file,
and when that file is saved, the file is marked as resolved.
But I can see that as yet another plugin, rather than a core thing (at
least in the beginning)

> 
> * add hooks for the new '--diff-prefix' option
> 
> 
> Let me know if you have any other suggestions for improvements.
> 
> -- Steve

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060430/fd292ed9/attachment.pgp