我们在映射的networking驱动器（Windows）上有一个Mercurial存储库（stable分支）。
我想知道如果多个用户同时尝试推送会发生什么情况。 或者如果有人拉着另一半正在推中途。
Mercurial客户端是否通知操作系统文件正在被另一个进程使用并释放？ 有没有这样的风险，我可以用这个设置来破坏存储库？
Mercurial使用locking文件来保护存储库免受并发更改。 只有一个用户可以一次抓住锁并更改回购，其他用户则获得“等待锁存储库”消息。
SMB支持锁，所以不应该有任何问题（TM）。
Mercurial旨在处理并发访问。 你可以有
hg push操作（一个写操作）和 hg pull和hg clone操作（读取操作） 同时。 换句话说，读者不必等待，也不必等待一个作者。 作家不得不等待其他作家。
正如pehrs所说，这是用锁来完成的。 但是，这不是通过使用文件系统锁来locking文件本身来完成的。 而是创build一个locking文件。
锁文件是支持它的系统上的符号链接，在其他系统上是正常的文件。 文件或符号链接包含获取该锁的进程的主机名和进程标识符（PID）。 这被用来检测陈旧的锁：如果获得锁的进程不再活着，那么我们可以安全地打破锁。
以上确保了一次只有一个进程将数据写入给定的存储库。 但是，使用networking文件系统时存在更多的危险。 一个潜在的问题是
$ hg clone foo bar
创buildfoo和bar之间的硬连接。 这样做是为了节省空间，并大大加快克隆操作。 如果一个新的提交是在bar ，Mercurial将会在写入新的数据之前仔细打破硬链接。 它基本上是
$ cp abc abc.tmp $ rm abc $ mv abc.tmp abc
确保文件abc不与其他人共享。 这只有在abc的链接数大于1的情况下才能完成。如果链接数是1，那么首先复制文件将是一个很大的浪费。 现在，问题是一些networking文件系统一直在撒谎链接计数到Mercurial！ 当他们报告两个或两个以上的时候，他们报告了一个，这使得Mercurial没有打破硬通道。 Mercurial 1.6.3在这种情况下有一个错误修正 – 当写入到networking驱动器时，Mercurial将无条件地断开硬链接。
因此，请确保您使用最新版本的Mercurial进行此类设置。