Results 1 to 8 of 8
  1. #1
    Join Date
    Apr 2013
    Posts
    9

    Default Integrating with Mercurial

    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

  2. #2
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,612

    Default

    Thanks, jffmarker.
    Aaron P Scooter Software

  3. #3
    Join Date
    Aug 2013
    Posts
    14

    Default

    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.

  4. #4
    Join Date
    Apr 2013
    Posts
    9

    Default

    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

  5. #5
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,612

    Default

    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.
    Aaron P Scooter Software

  6. #6
    Join Date
    Apr 2013
    Posts
    9

    Default

    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.

  7. #7
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    2,505

    Default

    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.
    ZoŽ P Scooter Software

  8. #8
    Join Date
    Apr 2013
    Posts
    9

    Default

    Thanks; that explains things...

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

    Code:
    #!/bin/zsh                                                                                                              
    
    /usr/local/bin/bcomp $*
    echo Press any key when done
    read

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •