opendiff tool slow to exit

  • I have got a question about the opendiff command-line tool that gets installed alongside FileMerge.app by the Developer Tools. The man page reads:

    ``opendiff is a command line utility that provides a convenient way to
        launch the FileMerge application from Terminal to graphically compare
        files or directories.  If FileMerge is already running, opendiff will
        connect to that running instance for the new comparison.
        opendiff exits immediately after the comparison request has been
        sent to FileMerge.''

    The problem is that on my machine, with FileMerge already running, opendiff does not exit immediately at all: there is a lag of about 1s between the moment when FileMerge opens the window as the result of opendiff requests and the moment when opendiff terminates. This is very annoying when used in the context of a code versioning system which may fire repeated calls to opendiff if asked to diff the changes in an entire directory for example: it means I have to wait 1s before each diff gets displayed by FileMerge.

    Has anybody experienced that lag too?

    I am running MacOS 10.6 with the latest version of the Developer Tools on a 1st gen Mac Pro with a RAID 1+0 made from 4 disks.



    Luc Bourhis
    Computer Scientist
    Chemical Crystallography Laboratory
    University of Durham, UK
  • Hello Chris,

    > I too noticed this recently when opening multiple Subversion files to resolve conflicts.
    > (It may only be a second, but it feels a lot longer.)
    >
    > The solution was quite simple (eventually).
    >
    > #!/bin/sh
    > ..
    > /usr/bin/opendiff "$left" "$right" -ancestor "$base" -merge "$f" &
    >
    > It's the magic trailing '&' that fixed it.

    Thanks for the suggestion. It seems to work with subversion indeed but not for the one tool I use most: git. Indeed the latter does the following sequence of operations:

    (1) create a temporary file for HEAD
    (2) ask the script like yours to diff that file and the working version
    (3) delete the file when the script returns

    The script executes too fast and by the time opendiff/FileMerge handle the request, the temporary file is gone and it results in a failure.

    I'll file a bug to Apple then!

    Thanks,

    Luc
  • On Tue, Aug 24, 2010 at 10:02, Luc Bourhis <luc_j_bourhis...> wrote:
    > Hello Chris,
    >
    >> I too noticed this recently when opening multiple Subversion files to resolve conflicts.
    >> (It may only be a second, but it feels a lot longer.)
    >>
    >> The solution was quite simple (eventually).
    >>
    >> #!/bin/sh
    >> ..
    >> /usr/bin/opendiff "$left" "$right" -ancestor "$base" -merge "$f" &
    >>
    >> It's the magic trailing '&' that fixed it.
    >
    > Thanks for the suggestion. It seems to work with subversion indeed but not for the one tool I use most: git. Indeed the latter does the following sequence of operations:
    >
    > (1) create a temporary file for HEAD
    > (2) ask the script like yours to diff that file and the working version
    > (3) delete the file when the script returns
    >
    > The script executes too fast and by the time opendiff/FileMerge handle the request, the temporary file is gone and it results in a failure.

    There's nothing "magic" about the trailing '&'.  It means "run the
    program in the background and return immediately", which is why it
    seems to make opendiff finish faster.  It doesn't actually speed
    things up, it just hides the slowdown.

    --
    Mark Wagner
  • On Tue, Aug 24, 2010 at 3:37 PM, Luc Bourhis <luc_j_bourhis...> wrote:
    > The problem is that on my machine, with FileMerge already running, opendiff does not exit immediately at all: there is a lag of about 1s between the moment when FileMerge opens the window as the result of opendiff requests and the moment when opendiff terminates. This is very annoying when used in the context of a code versioning system which may fire repeated calls to opendiff if asked to diff the changes in an entire directory for example: it means I have to wait 1s before each diff gets displayed by FileMerge.
    >

    Have you ever used TextWrangler?

    http://www.barebones.com/products/textwrangler/

    It includes a command-line tool called 'twdiff' that will open files
    for comparison in TextWrangler. It's not FileMerge, but it might
    launch more quickly for you. And who knows, you may prefer it to
    FileMerge anyway!

    --
    // jack
    // http://nuthole.com
    // http://learncocoa.org
  • On Aug 27, 2010, at 3:04 AM, Jack Nutting wrote:

    > On Tue, Aug 24, 2010 at 3:37 PM, Luc Bourhis <luc_j_bourhis...> wrote:
    >> The problem is that on my machine, with FileMerge already running, opendiff does not exit immediately at all: there is a lag of about 1s between the moment when FileMerge opens the window as the result of opendiff requests and the moment when opendiff terminates. This is very annoying when used in the context of a code versioning system which may fire repeated calls to opendiff if asked to diff the changes in an entire directory for example: it means I have to wait 1s before each diff gets displayed by FileMerge.
    >>
    >
    > Have you ever used TextWrangler?
    >
    > http://www.barebones.com/products/textwrangler/
    >
    > It includes a command-line tool called 'twdiff' that will open files
    > for comparison in TextWrangler. It's not FileMerge, but it might
    > launch more quickly for you. And who knows, you may prefer it to
    > FileMerge anyway!

    And, because people might not realize it, it's important to note that it's free!  It's the little sibling of BBEdit.  It's very nice, in my opinion.

    Cheers,
    Ken
  • On Aug 24, 2010, at 6:37 AM, Luc Bourhis wrote:

    > The problem is that on my machine, with FileMerge already running, opendiff does not exit immediately at all: there is a lag of about 1s between the moment when FileMerge opens the window as the result of opendiff requests and the moment when opendiff terminates.

    I've experienced this for years(?) and finally filed a bug report on it 8 months ago. Engineering has still yet to confirm the problem.

    --
    Seth Willits
previous month august 2010 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today