Windows 文件系统上的Mercurial remotes，而不是http服务器

我目前正在进行从svn到mercurial的迁移。我的需求是简单明了的，我需要对我们公司的内部网进行源代码控制。我到处都能看到通过IIS设置远程repo的例子。我只是不明白在服务器上共享有什么意义

我仍然可以使用NTFS权限在repos上设置授权和身份验证吗

我错过什么了吗

---

谢谢

与可写文件共享相比，您有很多理由更喜欢任何东西

本质上，它归结为，通过web方法进行推送的能力对某人造成的伤害是有限的。 另一方面，读/写共享是执行推送所必需的，但也允许用户删除整个回购、历史记录和所有内容

即使没有恶意意图，人们（或流氓软件代理）也会导航到随机网络共享，并意外地将文件拖到它不属于的地方

---

锁定你的电脑的最好理由不是因为你的同事觉得用一个未锁定的电子邮件帐户向人力资源部发送色情内容很有趣，而是因为一个清洁工用抹布和键盘能做的事情太神奇了。音乐库应用程序在扫描一个工作组中的所有共享，并小心地将其“移动”到某个人的库中时，也能找到令人惊讶的内容。

将存储库放在文件共享上是可行的，但这不是Mercurial团队推荐的方法

请参阅HG wiki上的“共享磁盘”部分：

通常仅限于内部网，由于网络文件系统可靠性的一般问题，一般不建议使用

一定要检查一下，因为他指出了另一个有效的缺点（有写权限的人从网络共享中删除内容，不管是有意还是无意）

如果您知道（并且能够接受）这些事情，那么将存储库放到网络共享上无疑是最简单的设置方法

我个人的经验是，只要Windows共享在“真正”的Windows机器上，它就可以完美地工作。
在工作中，我们在真正的Windows服务器上使用共享没有问题，但在家中，我遇到了NAS问题（其行为类似于Windows共享，但实际上在Linux上运行）。
您可以在这里阅读更多关于我的经历：

---

如果我强制执行权限以拒绝对根文件夹和.hg/*的任何删除，该怎么办？此外，只有dev组才允许对存储库进行读/写操作。远程回购还将由每个本地回购+真实备份进行备份。所以，我不认为这里有什么大问题。你是对的，当只有开发人员可以访问共享时，操纵的机会很小。我们也这样做，而且很有效。但是，即使开发人员都是技术人员并且知道他们在做什么：正如Chris在回答中指出的那样，有人意外地将文件夹拖到其他地方的可能性总是存在的。主要问题是，如果您失去了网络连接，或者服务器/共享有锁定问题（如NAS），然后，如果在推的中途发生了什么，就没有清理步骤了。无法保证存储库仍然有效。当然，在本地或服务器上都没有100%的保证，但当出现问题时，它正常运行的可能性会大大增加。是的，我知道。我们在工作中从来没有遇到过这样的问题（在使用汞将近两年之后），但我知道它随时都可能发生。问题是，托管存储库的所有其他方法似乎都很复杂，而且我从来没有时间去想它，而将存储库放在网络共享上很容易而且很有效（是的，以后可能会有一些问题，但一开始它很有效！）。不幸的是，我们必须在工作中自己托管代码（对于我的私人项目，我现在使用Bitbucket，但在工作中，外部托管代码不是一个选项）。