Issue #3763 closed

Opening diffs for multiple files at once from Windows Explorer context menu

Jurko Gospodnetić
created an issue

When I select multiple changed files in Windows Explorer and select the Visual Diff context menu item TortoiseHg attempts to diff two temporary folders containing the working folder & parent diffs. However, it seems that those temporary folders may get destroyed too soon and the opened diffing tool does not find them.

In my case, I'm using Beyond Compare 3 with the following TortoiseHg configuration:

merge = beyondcompare3

vdiff = beyondcompare3

beyondcompare3.executable = ${ProgramFiles(x86)}\Beyond Compare 3\BComp.exe
beyondcompare3.regkey =
beyondcompare3.regname =
beyondcompare3.priority = 1
beyondcompare3.gui = True
beyondcompare3.args = $local $other $base $output /lefttitle=local /centertitle=base /righttitle=other /automerge /reviewconflicts
beyondcompare3.diffargs = /lefttitle='$plabel1' /righttitle='$clabel' /expandall $parent $child

TortoiseHg version info:

version 3.0
with Mercurial-3.0+3, Python-2.7.6, PyQt-4.10.3, Qt-4.8.5

The same does not occur if I open a similar diff from any of TortoiseHg dialogs, e.g. commit, log or status view.

Hope this helps.

Best regards, Jurko Gospodnetić

Comments (20)

  1. Jurko Gospodnetić reporter

    Looked into this now using sysinternals' Process Monitor & Process Explorer and here's what I got:

    1. I have two modified files, select them both and choose TortoiseHg's Visual Diff option from the Windows Explorer context menu.
    2. explorer.exe starts thgw.exe with the command line "C:\Program Files\TortoiseHg\\thgw.exe" --nofork vdiff --listfile "C:\Users\Jurko\AppData\Local\Temp\THG439C.tmp"
    3. thgw.exe starts cmd.exe with the command line C:\Windows\system32\cmd.exe /c ""C:\Program Files (x86)\Beyond Compare 3\BComp.exe" /lefttitle="@1408:e372af7ff267" /righttitle="working files" /expandall "c:\users\jurko\appdata\local\temp\thg.ensk1z\Jurko.1.1408" "c:\users\jurko\appdata\local\temp\thg.ensk1z\Jurko.1""
    4. cmd.exe starts BComp.exe with the command line "C:\Program Files (x86)\Beyond Compare 3\BComp.exe" /lefttitle="@1408:e372af7ff267" /righttitle="working files" /expandall "c:\users\jurko\appdata\local\temp\thg.ensk1z\Jurko.1.1408" "c:\users\jurko\appdata\local\temp\thg.ensk1z\Jurko.1"
    5. BComp.exe starts BCompare.exe with the command line "C:\Program Files (x86)\Beyond Compare 3\BComp.exe" /lefttitle="@1408:e372af7ff267" /righttitle="working files" /expandall "c:\users\jurko\appdata\local\temp\thg.ensk1z\Jurko.1.1408" "c:\users\jurko\appdata\local\temp\thg.ensk1z\Jurko.1" /BCompWnd=$000708F0 and exits (!!!)
    6. BCompare.exe keeps on running while its GUI remains open.

    BComp.exe exited first, and cmd.exe exited right after it.

    After copying two such folders as TortoiseHg prepare for this diff, I tried running a similar Beyond Compare operation directly from the Windows command prompt and true enough - the same thing happens - BComp.exe process exits before its related BCompare.exe finishes with its diff operation. BCompare.exe does not complain about missing folders this time though, of course, since no one deleted them on BComp.exe exit.

    Then I took a look at what happens when I run a matching operation from TortoiseHg's File Status dialog, and yup, sure enough - we get the same process start/exit pattern, but I guess this time the temporary folders are not removed until TortoiseHg's File Status dialog closes.

    In case you run BComp.exe while another BCompare.exe process is already running, the newly started BCompare.exe process will terminate immediately, and the original BCompare.exe will display the requested diff.

    Beyond Compare 3 version information: 3.3.10 build 17762

    My guess is that this either never worked with Beyond Compare or their BComp.exe starter started acting differently than before from some version.

    One possible workaround for using Beyond Compare in this scenario would be to pass in an additional /solo option. That would make the diff operation be run in a separate BCompare.exe process (as opposed to getting integrated into an existing one) and BComp.exe seems to wait for that to BCompare.exe to exit before exiting itself. Note that this would only need to be added when running from outside a TortoiseHg dialog where using an already existing instance might be what the user expects.

    Hope this helps.

    Best regards, Jurko Gospodnetić

  2. Yuya Nishihara

    If BComp.exe exits immediately, TortoiseHg (and hg extdiff) can't determine when to remove temporary files. So /solo option is requisite and the default mergetools.rc should have it.

    Thanks for the detail.

  3. Jurko Gospodnetić reporter

    I contacted Scooter Software about this and they say BComp.exe currently does not wait for folder compares, but that they are implementing that feature for Beyond Compare 4 (currently in a public beta). I'll give it a try later today and get back to you on how it goes.

    Best regards, Jurko Gospodnetić

  4. Jurko Gospodnetić reporter

    [Update: the testing done here seems to have been flawed as later retesting showed that Beyond Compare 4 still does not support this functionality.]

    I just got back to testing this Beyond Compare 4 (used version beta) and that version seems to correctly keep its BComp.exe process open in all cases that I tested.

    Here's a quote from the feedback I sent back to Scooter Software:

      Just tested this and it works exactly as I would expect. :-D
      BComp.exe correctly waits for its folder diff operation to
    complete. It even does so correctly if its own BCompare.exe
    process exited after it let a pre-existing BCompare.exe take
    over the operation.
      BComp.exe also correctly detects when BCompare.exe closes
    a tab related to its operation, even if the BCompare.exe still
    remains open (whether it shows other tabs or not).
      It does not stay open if another tab started diffing the same
    content, but I guess there is nothing much Beyond Compare
    can do about this in general. After all - it does not know that
    the data being compared is only temporary and will go away
    after the operation.

    Hope this helps.

    Best regards, Jurko Gospodnetić

  5. Jurko Gospodnetić reporter

    Just got around to retesting this and it seems I was mistaken the first time around. cry

    I must have made some sort of a configuration mixup because now, with more careful testing, Beyond Compare 4 does not seem to work as we'd like without the /solo option.

    I'll try to keep track of this and let you know when the needed Beyond Compare 4 functionality gets implemented, but for now, I'd leave the default configuration as it stands.

    I do not think it's worth the effort introducing new configuration & usage complexity by separating diff options used when running the operation from a Windows Explorer as opposed to those used when running a similar operation from a TortoiseHg dialog.

    Feel free to close the issue, and sorry for the noise.

    Best regards, Jurko Gospodnetić

  6. Jurko Gospodnetić reporter
    • changed status to open

    Just retested using the latest Beyond Compare 4 version - 4.0 beta (build 18291) and now everything works fine even without the /solo option if you use BComp.exe instead of BCompare.exe.

    One consequence this has is that you can no longer simply read the exe path directly from a registry value, since only the BCompare.exe executable is registered there.

    I tested:

    1. Starting a new Beyond Compare instance with one comparison & closing it.
    2. Starting a new Beyond Compare instance with one comparison, starting a second comparison, closing the second comparison, closing the first comparison.
    3. Starting a new Beyond Compare instance with one comparison, starting a second comparison, closing the first comparison, closing the second comparison.
    4. Starting a new Beyond Compare instance with one comparison, opening a new empty session, closing the initial comparison.

    And BComp.exe processes die correctly exactly when their tabs get closed, effectively allowing TortoiseHg to simply wait for the BComp.exe process to terminate in order to find out that the user is done with the folder diff operation.

    Hope this helps.

    Best regards, Jurko Gospodnetić

  7. Jurko Gospodnetić reporter

    Nah, I can see only the following settings there:

    Windows Registry Editor Version 5.00
    [HKEY_CURRENT_USER\Software\Scooter Software\Beyond Compare 4]
    "ExePath"="C:\\Program Files (x86)\\Beyond Compare 4\\BCompare.exe"
    [HKEY_CURRENT_USER\Software\Scooter Software\Beyond Compare 4\BcShellEx]
    "RegistryViewer"="Registry Compare"
    "Viewers"="Text Compare;Table Compare;Hex Compare;MP3 Compare;Picture Compare;Registry Compare;Version Compare"

    So the workaround I use is to set the following TortoiseHg configuration:

    beyondcompare4.executable = ${ProgramFiles(x86)}\Beyond Compare 4\BComp.exe
    beyondcompare4.regkey =
    beyondcompare4.regkeyalt =
    beyondcompare4.regname =

    although I think only clearing beyondcompare4.regname should be enough to cancel the current defaults.

    Hope this helps.

    Best regards, Jurko Gospodnetić

  8. Jurko Gospodnetić reporter

    Yup but using BComp.exe provides a nicer interface, as your diff operation integrates into the already open Beyond Compare GUI if possible. smile

    Anyway, for me - the situation is good enough. I can now set it up the way I want to manually for myself. You can choose whether to update the defaults or not. smile

    Best regards, Jurko Gospodnetić

    P.S. Or I guess Mercurial could learn to extract the base path from the BCompare.exe path read from the registry. smile

  9. Yuya Nishihara

    Yes, it seems BComp.exe is the right way to run Beyond Compare as merge/diff client.

    There are two options.

    • patch Mercurial to be able to strip filename part from regname,
    • or ask BC dev to add another registry key for BComp.exe (or installation directory.)

    Since BC4 is still in beta, we can change the default settings if new registry key is available.

  10. Jurko Gospodnetić reporter

    The first solution seems cleaner. BC is an external tool with its own integrations and external set of tools that rely on it. Asking it to change the way it stores its internal book-keeping just to make it easier for 'one specific external tool' (in this case Mercurial/TortoiseHg) to implement using that information seems smelly to me. Especially since the information they currently have there basically holds all the information required.

    That said, if you really want to try that, I can ask the developers there. I'm just saying that in this case I can sympathize with them simply discarding my request. smile

    Best regards, Jurko Gospodnetić

  11. Yuya Nishihara

    I hope somebody using BC will send patch to mercurial-devel.

    BTW, Beyond Compare will be the only tool that needs an option to strip filename from registry value.

  12. Jurko Gospodnetić reporter

    Just has an idea for a workaround without requiring a Mercurial patch. smile


    Tested and works on my PC. smile

    ProcessExplorer says the correct process gets started using the following path:

    "C:\Program Files (x86)\Beyond Compare 4\BCompare.exe\..\BComp.exe"

    Hope this helps.

    Best regards, Jurko Gospodnetić

  13. Yuya Nishihara

    Wow, magical Windows. I did try it on Linux and confirmed it didn't work because BCompare.exe is a file, but cmd.exe seems not caring such small things.

    I want to see if Mercurial devs accept this hack.

  14. Jurko Gospodnetić reporter

    Well if they call os.path.normalize() on the result, it should work on both, but then of course you have problems with symbolic links on Linux where a/b/../c does not necessarily have to be the same as a/c. smile

    Hmmm, I can't really give a clean solution to this mess off the top of my head, but for Beyond Compare 4 on Windows - this should work. smile

    Best regards, Jurko Gospodnetić

  15. Log in to comment