Issue #60 open

P3D3:: AFP : Cannot push/pull between two repositories ...

richard_liu
created an issue

.. if one of them is a shared device. Hg is running on a MacBook Pro. It is connected to a LAN, as is a Mac Pro. On the Mac Pro System Preferences | Sharing | File Sharing is on, so the Mac Pro shows up as a shared device in the Finder on the MacBook Pro. So in Hg I define a local repository by navigating to the correct folder. Then I clone it and create another local repository (which is really local), then make a few modifications to the files in the clone and commit them. When I then attempt to push the changes to the share, or pull them from there, I receive a message that Hg timed out waiting for a lock held by ''.

Comments (19)

  1. Jason Harris repo owner

    Thanks Richard for the report, and thanks for moving it!

    However, I still can't seem to reproduce this... I am sharing files from my MacMini (my pseudo server) and I can push and pull to these LAN connected repositories just fine.

    So likely there is some difference in your setup or mine... Can anyone else reproduce this?

    Thanks! Jas

  2. richard_liu reporter

    (Reply via ric...@pueo-owl.ch):

    Jason,

    Thanks for your time. I didn't register at first because I didn't know = that there is a free plan.

    What are the properties of the bookmark for the LAN connected = repositories on the MacMini? Mine have names that begin with = /Volumes/...

    Regards, Richard

  3. richard_liu reporter

    Jason,

    Just tried again with push and pull. Same result. Something is holding a lock. So, after waiting and waiting, Hg issues:

    Mercurial reported error number 255: waiting for lock on repository /Volumes/sim/RDR Classification/Development/Programs held by '' abort: repository /Volumes/sim/RDR Classification/Development/Programs: timed out waiting for lock held by

    In the error message you can see the repository (remote) that I was pulling to. The repository that I was pulling is /Users/sim/RDR Classification/Development/Programs.

    Regards, Richard

  4. Jason Harris repo owner
    • changed status to open

    Richard,

    No problem at all about the anonymous first report, it just makes it hard for me to address whoever and communicate with them :)

    Anyway, the next question, do you have hg installed but not from MacHg? If so does the push and pull work from the command line instead of through MacHg?

    Cheers, Jas

  5. richard_liu reporter

    (Reply via ric...@pueo-owl.ch):

    Jason,

    Sorry to have taken so long getting back to you.  I noticed that the two accounts between which I am pushing/pulling, one on each Mac, had some problems.  I was not even able to write files on one machine from the other.  So I fixed that by recreating one account manually.  I had previously used Migration Assistant on the new MacBook Pro to migrate the account from the Mac Pro.

    But the problem persists.  I create a repository on the MBP by cloning one on the MP.  Then I make a change to a file in the repository on the MBP and commit it.  When, on the MBP, I push the changes back to the MP I get the message that the push timed out waiting for a lock. Doing a pull from the MP times out with the same error message.

    Time to consult Dr. Google, I thought.  Here's what he found:  http://www.selenic.com/pipermail/mercurial/2008-February/017066.htm.  This seems to be what's happening to me, but the bug report is quite old.

    As I am no Hg expert I don't have any other version of Mercurial other than MacHg, but perhaps this might help you reproduce the problem.

    Regards, Richard

  6. richard_liu reporter

    Jason,

    I've found a solution to the problem without knowing exactly what was causing it. After deleting the account that I had migrated from the Mac Pro to the MacBook Pro and setting it up manually, I tried using MacHg to clone the repositories on the Mac Pro to the MacBook Pro; however, it seems that doing this previously with the migrated account had somehow corrupted (or locked?) the repositories on the Mac Pro. After setting them up again I was able to clone them to the MacBook Pro, then to modify them there and push the changesets back to the Mac Pro. Pulling from the Mac Pro also works. So it seems that I'm in business again.

    Lesson: Migration is for moving an account, not for duplicating. If it's used for duplicating, ensure that the original and migrated accounts never share files.

    Regards, Richard

  7. Jason Harris repo owner

    Thanks for getting back to me. I think this is likely a problem in core Mercurial, and as such is not a MacHg issue. I'll close this issue for now then, but keep it around in case others see such a thing in the future.

    Resolving as possible Mercurial problem / not-reproducible...

    Thanks! Jas

  8. Anonymous

    I encounter this issue intermittently if I'm too fast on a push after a commit. The problem is, MacHG is very poor at indicating whether or not it is finished a task. It may appear to be finished, and refresh takes place, but if you push too fast, it locks up. Very frustrating needless to say.

  9. Anonymous

    deleting the wlock file and retrying the commit/push in terminal does seem to resolve it however. Nevertheless, this should be addressed as it can be a serious problem.

  10. Anonymous

    this is now a reoccurring issue and it's really becoming a serious problem. Locks appearing on normal MacHg usage and no way around them. I'm the only one in my org using MacHg so this could in fact be a macHg issue.

  11. Anonymous

    I am using Mercurial on a PC and on a Mac. At the PC I am using TortoiseHg and on the Mac MacHg as graphical user interface. My repositories usually are located on a samba fileserver. On the PC I do not have any problems using TortoiseHg on both the local and the remote samba filesystem. At the Mac MacHg works on local directories as expected. But when trying to create a repository on the samba server I get the following error message: "Mercurial reported error number 255: skipping unreadable ignore file <path> ... waiting for lock on working directory <path> ..."

    This is strange, because the error message is coming on our new samba server only. As long as I was using the old one, everything works fine with MacHg even on remote repositories on the samba server. The only difference between both servers is the samba version number (3.0.x vs. 3.2.5). The configuration is equal apart from version specific default.

    Hope this helps to locate the source of the problem.

  12. Jason Harris repo owner

    Even though this is a Mercurial problem: I am still interested in this. If someone can repeatedly reproduce this can they send me the log file. Do this by

    1. Set logging to full in the MacHg preferences.
    2. Quit MacHg and restart it to clear the logs again.
    3. While doing as few steps in MacHg as possible in order to keep the log small, recreate the problem.
    4. Quit and send me the log.

    Thanks, Jas

  13. Anonymous

    This issue appears every single time I try to push to our central repository. I never had this problem with command line hg, only with MacHg. Needless to say, it is very annoying having to reboot the system every time I need to push...

  14. susanlitton

    I'm having a similar or the same issue - can't push or pull - get this error:

    Mercurial reported error number 255: pushing to http://xxxxxxx:***@xxx.xxx.xxx.xxx:8086/ searching for changes

    I tried rebooting but it didn't help. I had just committed some work, then was trying to push when it first happened. I see others talking about deleting the wlock file. Where do I find that?

    I'm on a MacBook Pro.

  15. susanlitton

    If anyone is following this thread, nothing I tried fixed the issue above and I also couldn't execute any Mercurial commands from the Terminal. I got the "abort: requirement 'dotencode' not supported!" error message from the Terminal and I knew we hadn't changed Mercurial versions. What I finally did was to delete the entire repository and clone a new one. That worked, so I'm up and running again which is the most important thing, but I still don't know what happened.

  16. Log in to comment