hg repositories and Windows DFS Replication

Adrian Buehlmann adrian at cadifra.com
Wed Jun 1 02:11:47 CDT 2011


> On Tue, 2011-05-31 at 21:56 -0500, Robert Altman wrote:
>> The only problems I have seen with DFS are when copying large files (>100's
>> MB).  If you try moving or renaming a large files while it is being
>> replicated, the operation may fail with file-in-use error.

Then this is completely unsuitable for use with Mercurial on Windows and
might lead to repository corruption - not just for large files. [1]

Mercurial was designed for POSIX-like file systems and Windows isn't. We
(or rather Matt and contributors) mimicked POSIX-like file access on
Windows by using a wrapping layer. At the core of this is a file pattern
that renames a file to a temporary name before re-writing the original
file. [2]

So, locking a filename while replicating it is a big NO for Mercurial
repositories. It breaks the assumptions Mercurial makes about a file system.

If you intend to ponder deeply about file system access on Windows and
Mercurial see:
http://mercurial.selenic.com/wiki/UnlinkingFilesOnWindows
http://mercurial.selenic.com/wiki/HardlinkedClones

[1]
Luckily, thanks to the decent architecture of Mercurial, we have a 'hg
verify' command that finishes in reasonable time, so, at least, 'hg
verify' can be used to detect such corruption -- other DVCS' either
don't yet have a verify command - cough, hi Veracity - or are slow like
hell so almost nobody ever checks the integrity of their repos - cough,
hi Bazaar.

[2]
People may argue that re-writing isn't used because they heard someone
saying that Mercurial does "append only" inside the store (.hg/store).
But Mercurial needs to break up hardlinks inside the store, and there,
that pattern is absolutely needed on Windows. Besides that, operations
that switch an inlined *.i file to a *.i / *.d file pair in the store
are not 'append only' at the files layer either.


More information about the Mercurial mailing list