Issue #1 resolved

P4D5::Outdated bundled Mercurial

Anonymous created an issue

I'd like to see some way to use an external Mercurial. The bundled version is from last November and there have been six releases since then.

Comments (5)

  1. Jason Harris repo owner

    Thanks for your comment.

    Its that way for stability for now. When more testers are up and running I will change this. There is an option to use an external mercurial but just before the 0.9.0 release I pulled it. (See UseWhichMercurialOption in Common.h and you can search the code to see its in place.) Having an older mercurial binary doesn't make too much difference from the point of view of MacHg since MacHg is the entire "FrontEnd" to the Mercurial functionality. Ie if there is some new feature or enhancement in Mercurial 1.5.2 that is not present in 1.4.1 then since MacHg is not using this enhancement it doesn't matter in any case. (Note for example that bit bucket is using Mercurial 1.3.1)

    However, I will reinstate the option again in the future after things have stabilized a bit. Also there is an issue with the way current mercurial binaries write to the current directory each time a status update is done. This causes the auto checking for changes in MacHg to think something has changed and it does a status update again, which causes mercurial to write a temp file again and MacHg thinks again something has changed and so on... Check the mercurial newslist archives for a description of the problem. But if you want to use 1.5.2 or something you can just drop it right into place and apply the following patch to stop the racing in the file check status of Mercurial. In fact if you tell me who you are and I can get say 2 other testers that want to test this, I'll make a branch of MacHg and you can test the new version out.

    # HG changeset patch
    # User jfh <>
    # Date 1271196541 -7200
    # Node ID a19192b2ff533a82e452eefec8a44ae430ef6971
    # Parent  52dc89046ae8291cf36ac3ae8b6eeb9912aa654e
    - Use the standard temp directory rather than the given directory since it stops racing on
    diff --git a/LocalMercurial/mercurial/ b/LocalMercurial/mercurial/
    --- a/LocalMercurial/mercurial/
    +++ b/LocalMercurial/mercurial/
    @@ -641,7 +641,7 @@
             EXECFLAGS = stat.S_IXUSR | stat.S_IXGRP | stat.S_IXOTH
    -        fh, fn = tempfile.mkstemp("", "", path)
    +        fh, fn = tempfile.mkstemp(dir=None,prefix='hg-check-exec-')
                 m = os.stat(fn).st_mode & 0777
    @@ -659,7 +659,7 @@
         """check whether the given path is on a symlink-capable filesystem"""
         # mktemp is not racy because symlink creation will fail if the
         # file already exists
    -    name = tempfile.mktemp(dir=path)
    +    name = tempfile.mktemp(dir=None)
             os.symlink(".", name)

    Cheers, Jason

  2. Lee Cantey

    Hi Jason,

    Sorry, I thought I was logged in earlier but apparently not. I did notice the race once where it was constantly updating the information panel but it stopped somewhere along the line. I'll give your patch a test, thanks.

    I'd noticed the version issue after I started playing with the proposed eol extension which requires a later Mercurial.

    Regards, Lee

  3. Jason Harris repo owner

    Ok they changed things a bit so that patch is rejected...

    I just assembled a version of MacHg with a patched Mercurial1.5.2 at

    Interestingly I just tried some testing on my large test repository (its the open office repository at 3.35Gb)

    MacHg 0.9.0 with Mercurial 1.4.3 (I think thats the one but can't remember... :) ) to open this took (4 run time trial)

    4.8 seconds 5.4 seconds 5.0 seconds 5.2 seconds

    and MacHg 0.9.0 with Mercurial 1.5.2 to open this same repository (4 run time) took

    6.4 seconds 5.8 seconds 6.6 seconds 5.9 seconds

    so it seems a bit slower... I guess I will tell the devs about this since a 20% speed hit when upgrading is something to take notice of...

    Can you test out the various bits and give MacHg with this a good kicking over? :) I'll put in a branch soon but of course everything could work except for (I dunno adding bookmarks) or something, and since its hard to test everything stability was more important in my initial release...

  4. Log in to comment