Integrating with Mercurial

[jffmarker]

This has been working for me for diffing and merging via Mercurial 2.4.2... pretty much verbatim from other OSes.

[ui]
merge = bcomp

[extensions]
extdiff =

[extdiff]
cmd.bcomp = /usr/local/bin/bcomp
#opts.bcomp = -ro

[merge-tools]
bcomp.executable = /usr/local/bin/bcomp
bcomp.args = $local $other $base $output
bcomp.priority = 1
bcomp.premerge = True
bcomp.gui = True

[Aaron]

Thanks, jffmarker.

[Dov]

When I configure my .hgrc file the same as above, the hg bcomp command successfully launches Beyond Compare, and I can view the folder diff, but when I double click on any files to do a file comparison, both sides show Unable to open file "/private/var/folders..." under the path bar, with a red circle X.

I also notice, and this may be the cause, that after I enter the Mercurial command, I'm back at the command prompt immediately - it's not waiting for BC to finish the session or quit. Both the "bcomp" and "bcompare" executables behave the same way.

I'm running version 2.4+20121101 of Mercurial.

[jffmarker]

I also encountered this recently when trying to diff multiple files... I'm not sure if I didn't try this case when I first wrote this, or whether something changed. I came to the same conclusion as you regarding HG not waiting for BC to finish before cleaning the temp files.

The HG documentation for ExtDiff describes a workaround for FileMerge, which also "returns immediately". See section 'FileMerge on Mac OS X' here: http://mercurial.selenic.com/wiki/ExtdiffExtension

However, giving that a quick try didn't seem to help me, but I haven't had more time to devote to it to see if it just needs some tweaking.

While this is messy (and seemingly not recommended), has been functional for me:

[extdiff]
# cmd.bdiff = /usr/local/bin/bcomp
cmd.bdiff = /Applications/Beyond Compare.app/Contents/MacOS/BCompare
# opts.bdiff = -ro

[Aaron]

In general, BC4 does not currently support a folder level diff from a VCS. If so, it depends on the folder paths existing in accessible locations and correctly passed to BC4. Otherwise, you would need to diff or merge specific files. Enhancing this is on our wishlist.

[jffmarker]

I understand it seems like you're at the mercy of HG here, since it appears it's not waiting for you to be done with the files before cleaning them up. One can hope a workaround is possible similar to what they've posted for FileMerge... forcing BC to squirrel files away somehow so it can work after the fact seems finicky at best.

What my assumption is, is that HG creates a temp folder with the original files, tells BC to compare the temp folder with the real folder (which seems to work), but then cleans up the temp folder from under it... the trick being needing to keep the temp folder around so BC can work with the files in it. I think the actual setup and communication with BC works.

[Zoë]

It's actually a limitation of Beyond Compare's interprocess communication:

1) OS X in general only allows a single instance of GUI process at once. We manually implemented the same behavior on Windows in v3 to allow program state to be shared easily regardless of whether you're using separate windows or tabs.

2) Mercurial launches a diff, waits for the process to finish, and then deletes the files. That's about as good as it can do.

3) We have a launcher script, bcomp (bcomp.exe on Windows) that is designed to handle that behavior. When it's run it passes its command line parameters to the existing copy of BC if one's running, or starts a new copy if it isn't. It then waits in memory until BC tells it that the user has closed that particular comparison. At that point Mercurial can correctly clean up the temp files.

The problem is that when we implemented that behavior, version control systems didn't do directory-wide diffs, so we didn't support waiting for folder comparisons. If bcomp calls BC with a folder compare BC it just responds immediately with "Waiting not supported", so bomp closes and Mercurial cleans up after itself.

On Windows you can work around that limitation by always launching bcompare.exe directly with the /solo switch, but OS X doesn't support that (and we can't really add it). Waiting for directory compares is becoming a more glaring issue though, and I would like to get it in before v4 launches.

[jffmarker]

Thanks; that explains things...

I suppose as a temporary workaround one can redirect HG to a script that can manually wait, such as:

#!/bin/zsh                                                                                                              

/usr/local/bin/bcomp $*
echo Press any key when done
read