Bazaar as Subversion replacement

[John Arbash Meinel]

Alexander Belchenko wrote:
> John Arbash Meinel ?8H5B:
>> Aaron Bentley wrote:
>>> Nicholas Allen wrote:
>>>>> 5 Olive: No easy way to see differences in a graphical diff program such
>>>>> as Beyond Compare.
>>> I expect it's a few hours' work, given an interested developer.
>>> It's easy enough with the difftools plugin, though.
>> I thought Olive had a built-in diff between revisions. Specifically the
>> same diff as provided by 'bzr gdiff' (when you install bzr-gtk). And the
>> same one that shows up when you double click a line in 'bzr gannotate'.
> 
> gdiff is not very useful at this moment. It's even don't have coloring
> of diff!

Which is funny because 'bzr viz' has supported colored diffs for a long
time. And the dialog looks a lot like the old 'bzr viz' version of diff.
 So I wonder what happened to the coloring.

But it sounds like Nicholas wants a side-by-side view (since you can't
really edit in a unified diff view).

Certainly expanding 'gcommit' a bit would be reasonable. I cringe a
little bit at doing that sort of work at commit time. But I guess my
current workflow is to do 'bzr diff' review it, modify if necessary,
then 'bzr commit'. Which sounds like what Nicholas wants. Just that he
is used to programs doing all of the diff/review/edit/and finally commit
with the command 'commit'.

I guess for a GUI, it is approximately the right time to do it. Though I
can see reviewing the commit, and realizing you need to go modify
another file, at which point you need to start all over again.

So some of it is having the "right" workflow. Which might be just
copying the workflow of something like Tortoise, *because* it is what
people would be used to. I'm not sure it is the 100% right workflow, but
it certainly could be a good starting point.

Some of the limitations of Tortoise is because it isn't a standalone
program, it integrates into the Explorer shell.  Which means that you
don't have a good way to define a custom workflow. It has advantages (#1
being user comfort, since they don't feel like they are learning an
entirely new program).


> 
>> I suppose he is asking to be able to spawn a third-party diff program.
>> But we have basic for that in the 'difftools' plugin, which will likely
>> be merged into core. (bzr diff --using meld).
> 
> Because Nicholas wants cross-platform solution I don't know is meld
> works properly on win32?
> 
> Alexander

Last time I tried, meld depended on 'gnome', and pygnome had not been
ported to Win32. (pygtk had, but not pygnome). I remember looking into
it a little bit and the dependency wasn't very strict, but stuff like
user-preferences used the gnome interface. (Which is actually pretty nice).

But difftools also supports a bunch of other programs (kdiff3, vim,
etc), and it should be pretty easy to implement a new one. The only
reason we need an interfacing layer at all is because none of the
programs conform to a standard. (Some take the modified file first, some
take the original first, some only support file-by-file, some do whole
trees, etc)

So adding support for "Beyond Compare" should be easy, as long as Beyond
Compare can be easily scripted. (Since it sounds win32 specific, it may
be a little bit trickier, but you can always write a wrapper that spawns
and uses DDE to control it, it is just more work)

John
=:->