这与我的安全问题here有些关联。在实时网站上使用hg / mercurial存储库是一个坏主意吗？如果是这样，为什么？
此外，我们还有我们网站的开发，测试和制作安装，例如dev.example.com，test.example.com和www.example.com。如果将一个存储库用于实时/生产网站是个坏主意，那么可以在开发和测试网站上使用hg存储库吗？
我也很关心部署的简易性。我们有技术和技术较少的同事将与该网站合作。技术人员（软件工程师）在使用命令行或TortoiseHG时不会有任何问题。我更关注技术水平较低的人（网页设计师）。他们不习惯在命令行上工作，甚至可能会发现TortoiseHG令人生畏。这些同事主要将.css个文件和图像上传到服务器。我希望这些文件（至少.css个文件）受版本控制，但我希望这对非技术团队成员尽可能透明。
实现这一目标的最佳方式是什么？
编辑： 我们的“站点”实际上是一个多站点CMS设置，具有主存储库和多个子存储库。存储库结构的模拟：
/root [main repository containing core files and subrepositories]
/modules [modules subrepository]
/sites/global [subrepository for global .css and .php files]
/sites/site1 [site1 subrepository]
...
/sites/siteN [siteN subrepository]
软件工程师可以在root，modules和sites/global存储库中工作。技术人员较少（网页设计师）只能在site1 ... siteN子存储库中使用。
答案 0 :(得分：4)
是的，这是一个坏主意。
不要将您的存储库作为您的网站。这意味着签入但不工作的东西将立即可用。这意味着偶然的签到（它会发生）也会被现场反映（即那些不属于那里的文件等）。
我实际上用我编写的工具解决了这个“概念”（源代码控制作为部署）（其他一些公司现在正在解决这个问题，所以你会看到更多）。我的是SVN（目前），所以它并不是特别相关;我之所以提到它只是为了表明我之前已经考虑过这个问题（不是在存储库中;工作副本，在这种情况下，答案是相同的：更好的是将非版本化的“免费”作为网站目录，并且自动化（通过用户操作）将“版本化”数据复制到该目录。）
答案 1 :(得分：4)
许多人将他们的网站保存在存储库中，只要您没有人实时编辑实时网站就可以了。有一个staging / dev区域，非版本控制人员会在这里进行更改，然后让更多RCS友好的人定期执行commit-pull-merge-push循环。
只要这是判断人类做分期区域的有意识行动 - ＆gt;生产回购让你很好。您甚至可以将钩子放入生产克隆中，自动对该生产克隆中的工作目录进行“hg update”，这样就可以“推送”部署所需的全部内容。
那就是说，我认为你低估了你的网络团队或者tortoiseHg;他们可以得到这个。
答案 2 :(得分：2)
我个人（我是一个团队），我非常喜欢将src控件用作实时网站的想法。用hg更多，然后用svn。
我看到它的方式，您可以使用单个cmd加载整个站点，（添加/删除文件） 比ftp / ssh更容易，删除等等
如果您正在使用apache（也可能是iis），您可以创建一个简单的.htaccess文件来阻止所有.hg文件（如果使用svn则为.svn）
我的首选结构是 开发站点位于直接从存储库运行的本地计算机上（这里不需要安全性，根据需要执行您喜欢的操作）
staging / test machine是一个单独的框或vm，它运行最新的实时数据库副本 （我有一个脚本将已提交的更改推送到登台服务器并运行测试）
直播机 （打开ssh连接，将更改推送到实时服务器，再次测试，可以很容易地编写脚本，google为例）
由于hg的推/拉性质，这意味着您可以提交更改并进行测试，而不会将破坏的构建推送到实时网站。就像你在评论中说的那样，只有特定的人才有权将版本推送到实际网站。 （如果失败，您应该可以通过src控件轻松恢复到以前的版本）
答案 3 :(得分：0)
为什么不让repo成为活跃的Web服务器（无论如何还是开发或测试/ QA环境）？
以下是我要实施的内容：
将在Dev上合并和测试更改，然后推送到Test / QA，依此类推。
是的，我们正在使用Mercurial。我相信这个模型只能使用分布式源代码管理工具。