我正在寻找一种解决scheme，可以以尽可能不干扰的方式在公司环境中安装版本控制。 我正在考虑的一个可能的解决scheme是在每个Windows桌面上设置好mercurial，并在共享上设置工作副本。 所以不会有安装mercurial的服务器。 显然，这并不能同时解决同一文件中的多个用户，但这不是我们正在努力解决的问题。 这不是备份，但是再次版本控制不应该是备份。 另外我们有很多的备份。
这个设置是否正常工作？ 将提交日志中的用户名logging正确。 或者一切似乎都是由同一个用户提交的？ 任何人有任何这种设置的经验？
是的，你可以做你的build议。 现代版本的Mercurial并不关心工作副本的存储位置 – 它们可以存储在本地磁盘或networking文件系统中。
过去我们遇到了一些问题（在版本1.7.1之前），Mercurial将无法打破存储在networking文件系统中的存储库中的硬链接。 问题是如果你使用hg clone foo bar话，两个版本库将在服务器上被硬连接。 如果用户推送一个提交，并通过networking共享访问存储库，那么Mercurial发现bar/.hg/store里面的文件被硬链接到foo/.hg/store非常重要的，这样可以打破链接。 由于Windows和Linux中的各种内核错误 ，旧版本的Mercurial可能会失败。
因此，回顾一下：如果您只在所有客户端上安装Mercurial，则服务器不需要安装Mercurial。 创build（我希望我记得正确的UNCpath）
\\server\share\main
作为主要的存储库并为开发者制作克隆：
\\server\share\alice \\server\share\bob
爱丽丝和鲍勃将在那里工作，并独立修改工作副本。 他们作出正常的承诺，当他们准备好时，他们推回到main回购。 用户名存储在变更集中，所以当变更集进入主库时，它们将被保留。
在networking共享上创build共享的基准存储库。 让所有的用户都做'hg clone'来得到这个版本库的一个本地拷贝，让它们在本地拷贝上工作（编译，编辑'hg add / … / commit'）。 每当有人准备将其本地更改推送到共享存储库时，让他们执行“hg push”。 每当有人想让其他人推送到共享库时，让他们做'hg pull'和'hg update'。 这就是简而言之。
几个注意事项：
对共享存储库的并行读取/写入访问不成问题。 与其他类似的系统一样，Mercurial已经被明确地devise来处理这个问题。
共享存储库的本地副本是您的备份。
连接到提交的用户名必须在Mercurial的每个本地安装中的“mercurial.ini”文件中手工configuration。 我不知道是否有办法在该文件中使用类似％USERNAME％的内容，这可能会扩展到当前login的名称。
一个常见的做法是避免在共享存储库中存在多个头（如果不知道它在说什么，现在就忽略这个子弹头）。 为此，即将推出更改的用户通常会首先提取其他人所做的更改，并确保其本地更改与其他人所做的更改兼容。 冲突解决部分由“hg merge”完成。 大多数冲突都会自动解决，但有些需要用户干预（例如，如果你和我在同一个文件中编辑同一行，就会发生冲突，而我们越慢就必须处理，并编辑最终的线手动）。
由于我们正在处理Windows，我build议强制所有的文件名小写（或大写，如果你喜欢喊）。 对于最新版本的Mercurial，这可能不是绝对必要的，但是我们仍然只是为了安全起见（当然，因为Mercurial认为'a.txt'与'A'不是同一个文件。 txt“在基于Windows的系统上，它打破丑陋）。
祝你好运。