there appears to be a problem tracking clones located on the same mapped network drive. testing procedure: on mapped network drive z:\ created dir "original" and initialized. created a file, added the file, committed. cloned "original" to "testClone" made changes to the file in "original" and committed. hg log shows the same output in "original" and "testClone" on mapped network drive z:\ created dir "repo1" and initialized. created a file, added the file, committed. created dir "repo2" and initialized. created a file, added the file, committed. made changes to the file in "repo1" and committed. hg log shows the expected differences on local drive c:\ created dir "original" and initialized. created a file, added the file, committed. cloned "original" to "testClone" made changes to the file in "original" and committed. hg log shows the expected differences on mapped network drive z:\ created dir "original" and initialized. created a file, added the file, committed. cloned "original" to another mapped network drive "w:\testClone" made changes to the file in "original" and committed. hg log shows the expected differences
I'm seeing this on Windows as well, clone doesn't work on network drives. This is a severe bug, it makes mercurial basically unusable under windows for me. The networked drives all use NTFS if that makes any difference.
When cloning, we try to hardlink first and default to copying data if it fails. My tests on mapped drives show that hardlinking succeeds but GetFileInformationByHandle() fails to report it. The best I come up with now is: diff --git a/mercurial/util_win32.py b/mercurial/util_win32.py --- a/mercurial/util_win32.py +++ b/mercurial/util_win32.py @@ -147,9 +147,17 @@ class WinOSError(WinError, OSError): self.win_strerror) def os_link(src, dst): - # NB will only succeed on NTFS try: win32file.CreateHardLink(dst, src) + # CreateHardLink sometimes succeeds on mapped drives but + # following nlinks() fail to detect the link. Check this + # immediately and bail out. + if nlinks(src) < 2: + try: + win32file.DeleteFile(dst) + except: + pass + raise OSError('hardlinks are not supported') except pywintypes.error, details: raise WinOSError(details) I cannot measure significant slowdown when run on an hardlink compliant device, and it fixes the clones on mapped drives. It's just ugly. If someone knows a more reliable system call to get the link count on a given file... I will push this one soon.
Fixed in crew and crew-stable as cacfeee38870
In main, resolving.
Reopening, from the mailing list: Ok, we discovered it back here 2.5 years ago: http://mercurial.selenic.com/bts/issue761 ..and never put together that a local clone (hardlinks ok) followed by a remote commit (hardlinks invisible) was a problem. Ouch.
Fix is in crew-stable: http://hg.intevation.org/mercurial/crew/rev/50523b4407f6
Fixed by http://hg.intevation.org/mercurial/crew/rev/50523b4407f6 Patrick Mezard <pmezard@gmail.com> win32: correctly break hardlinks on network drives (issue761)
Note: The fix was first released with mercurial version 1.6.3
--- Bug imported by bugzilla@serpentine.com 2012-05-12 08:44 EDT --- This bug was previously known as _bug_ 761 at http://mercurial.selenic.com/bts/issue761