将 Mercurial Repository 放在共享网络驱动器中是个好主意吗？
我们是一个由 3 名开发人员组成的小团队（老板、我和另一名开发人员，主要是远程工作），我的任务是为 Mercurial HG 设置存储库服务器。
看来我可以简单地将我们的集中存储库放在共享网络驱动器上。它的设置非常容易，但似乎存在我们任何人都可能滥用直接工作/修改源存储库的便利的风险。这就是为什么我正在考虑使用 HgWebdir 服务器作为控制对中央存储库的访问的方式。因此，不鼓励直接访问中央源存储库，但为了以防万一，共享驱动器将放在这里。
我想这是一个定义我们内部版本控制程序的问题，而不是一个真正的版本控制问题，但我仍然继续问这个问题。因为我觉得我没有足够的经验来做出决定，并且如果我不能 100% 确定我的理由和手段是有效的，那么我可能很难强制执行其他人应该使用版本控制系统的方式开发商。
编辑：
我发现使用版本控制软件的共享文件夹存在潜在问题。但是有人愿意更多地解释一下推送到共享文件夹时幕后发生的事情吗？我的理解是，共享驱动器本质上是共享链接/快捷方式，因此对于共享驱动器，本地计算机上的 Mercurial 仅持有该链接的锁，但事实是每个用户计算机可能有不同的 Mercurial 实例持有该链接链接锁定，而服务器的 Mercurial 实例将在物理驱动器上保留其自己的链接。我可以看到它很复杂，但是它怎么会失败呢？我可以理解结论，但无法自己将事实与结论联系起来
we are small team of 3 developers (Boss, me and another developer working mostly remote), and I am tasked to setup a repository server for Mercurial HG.
It seems like I can simply put our centralized repository on a shared network drive. It will extremely easy to setup, but seems like there is a risk that any one of us could abuse the convenient of working/modify the source repository directly. That is why I am thinking about using HgWebdir server as a way to control access to central repository. So directly access to the central source repository is not encouraged, but the shared drive will be here just in case.
I guess it is a question of defined our in-house version-control procedure, not a really version-control question, but I am still go ahead and ask the question. As I don't feel I am experienced enough to make the decision, and if I am not 100% sure that my reason and means a valid, it is probably hard for me to enforce the way version-control system should be used by other developers.
Edit:
I can see that there are potential issues on shared folder working with Version-control software. But anyone care to explain bit more what happened behind the scene, when pushes to shared folder? My understanding is that shared drive is essentially a shared link/shortcut, so for a shared drive, Mercurial on local machine is only hold the lock for that link, but the fact is that each users machine could had a different instance of Mercurial holding the links' lock, while the server's Mercurial instance will hold its own link on physical drive. I can see it is complicated, but how it is going to fail? I can understand the conclusion, but couldn't by myself link the facts to the conclusion
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不应将 Mercurial 存储库放置在网络服务器上的共享文件夹上，因为 Mercurial 无法在此类设置中的所有情况下可靠地保持锁定，并且在推送到该中央存储库期间，锁定对于避免损坏存储库至关重要。
事实上，我会删除“不鼓励”并将其替换为“不可能”，并且仅使用 hgweb 或
hgserve为存储库提供服务，前者是长时间运行的服务器的推荐设置。You should not place the Mercurial repository on a shared folder on a network server because Mercurial cannot reliably hold locks in all situations in such a setup, and during pushes to that central repository, locks are crucial to avoid corrupting the repository.
In fact, I would remove the "not encouraged" and replace it with "not possible", and only serve the repository either with hgweb or
hg serve, the former being the recommended setup for long-running servers.如果您有一个集中式服务器，您可以在那里安装 hgweb 并将其作为中央备份源进行推送和拉取。我们仍然有 Windows 2003 服务器（我无法改变这一点），并且通过在网络上进行一些搜索就能够找到有关如何在 Windows 服务器上设置 hgweb 的信息，尽管其中大部分涉及 Windows Server 2007。
If you have a centralized server you can install hgweb there and push and pull from it as a central and BACKED-UP source. We still have Windows 2003 servers (I am in no position to change that) and with a little searching on the web was able to find info on how to setup a hgweb on a Windows server though most of it referred to Windows Server 2007.