使用 hg 存储库作为网站
这与我的安全问题此处有些相关。对实时网站使用 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 子存储库中工作。
This is somewhat related to my security question here. Is it a bad idea to use an hg / mercurial repository for a live website? If so, why?
Furthermore, we have dev, test and production installations of our website, like dev.example.com, test.example.com and www.example.com. If it's a bad idea to use a repository for a live/production website, would it be OK to use an hg repository for the dev and test sites?
I'm also concerned about ease of deployment. We have technical and less technical co-workers who will be working with the site. The technical people (software engineers) won't have any problem working with the command line or TortoiseHG. I'm more concerned about the less technical people (web designers). They won't be comfortable working on the command line, and may even find TortoiseHG daunting. These co-workers mostly upload .css files and images to the server. I'd like for these files (at least the .css files) to be under version control, but I want this to be as transparent as possible for the non technical team members.
What's the best way to achieve this?
Edit:
Our 'site' is actually a multi-site CMS setup with a main repository and several subrepositories. Mock-up of the repository structure:
/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]
Software engineers would work in the root, modules and sites/global repositories. Less technical people (web designers) would work only in the site1 ... siteN subrepositories.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，这是一个坏主意。
不要将您的存储库作为您的网站。这意味着签入但不起作用的东西将立即可用。这意味着意外签入（它发生）也将实时反映（即不属于那里的文档等）。
然而，我实际上用我编写的工具来解决这个“概念”（源代码控制作为部署）（其他一些公司现在也正在解决这个主题，所以您会看到更多）。我的是 SVN（目前），所以它不是特别相关；我提到它只是为了表明我之前已经考虑过这一点（虽然不是在存储库上；工作副本，在这种情况下答案是相同的：最好有一个非版本化的“免费”目录作为网站目录，并且自动（通过用户操作）将“版本化”数据复制到该目录）。
Yes, it is a bad idea.
Do not have your repository as your website. It means that things checked in, but unworking, will immediately be available. And it means that accidental checkins (it happens) will be reflected live as well (i.e. documents that don't belong there, etc).
I actually address this "concept" however (source control as deployment) with a tool I've written (a few other companies are addressing this topic now, as well, so you'll see it more). Mine is for SVN (at the moment) so it's not particularly relevant; I mention it only to show that I've considered this previously (not on a Repository though; a working copy, in that scenario the answer is the same: better to have a non-versioned "free" are as the website directory, and automate (via user action) the copying of the 'versioned' data to that directory).
许多人将他们的网站保存在存储库中，只要没有人实时编辑实时网站就可以了。设立一个暂存/开发区域，让非修订控制人员进行更改，然后让对 RCS 更友好的人定期执行提交-拉取-合并-推送循环。
只要它是一个判断人类在中转区的有意识的行为 -> 就可以了。生产回购推送你没问题。您甚至可以在生产克隆中添加一个钩子，自动对该生产克隆中的工作目录进行“hg 更新”，这样只需“推送”即可进行部署。
也就是说，我认为你低估了你的网络团队或 tortoiseHg；他们可以得到这个。
Many folks keep their sites in repositories, and so long as you don't have people live-editing the live-site you're fine. Have a staging/dev area where your non-revision control folks make their changes and then have someone more RCS-friendly do the commit-pull-merge-push cycle periodically.
So long as it's the conscious action of a judging human doing the staging-area -> production-repo push you're fine. You can even put a hook into the production clone that automatically does a 'hg update' of the working directory within that production clone, so that 'push' is all it takes to deploy.
That said, I think you're underestimating either your web team or tortoiseHg; they can get this.
就我个人而言（我是一个 1 人团队），我非常喜欢使用 src 控件作为实时网站的想法。 hg 更是如此，然后是 svn。
在我看来，您可以使用单个 cmd 加载整个站点（添加/删除文件）
比 ftp/ssh 容易得多，删除它等
如果您使用 apache （也可能是 iis），您可以制作一个简单的 .htaccess 文件，该文件将阻止所有 .hg 文件（或 .svn，如果您使用 svn）
我的首选结构是
开发站点位于直接从存储库运行的本地计算机上（这里实际上不需要安全性，可以根据需要执行您喜欢的提交操作）
登台/测试计算机是一个单独的盒子或虚拟机，运行实时数据库的最新副本
（我有一个脚本可以将提交的更改推送到登台服务器并运行测试）
实时机器
（打开 ssh 连接，将更改推送到实时服务器，再次测试，都可以相当轻松地编写脚本，例如 google）
由于 hg 的推/拉性质，这意味着您可以提交更改和测试，而不会面临推送损坏构建的危险到实时网站。正如您在评论中所说，只有特定的人才有权将版本推送到实时站点。 （如果失败，您应该可以通过 src 控制轻松恢复到以前的版本）
me personally (i'm a team of 1) and i quite like the idea of using src control as a live website. more so with hg, then with svn.
the way i see it, you can load an entire site, (add/remove files) with a single cmd
much easier then ftp/ssh this, delete that etc
if you are using apache (and probably iis as well) you can make a simple .htaccess file that will block all .hg files (or .svn if you are using svn)
my preferred structure is
development site is on local machine running directly out of a repository (no security is really required here, do what you like commit as required)
staging/test machine is a separate box or vm running a recent copy of the live database
(i have a script to push committed changes to staging server and run tests)
live machine
(open ssh connection, push changes to live server, test again, can all be scripted reasonably easily, google for examples)
because of push/pull nature of hg, it means you can commit changes and test without the danger of pushing a broken build to the live website. like you say in your comments, only specific people should have permission to push a version to the live site. (if it fails, you should easily be able to revert to the previous version, via src control)
为什么不让一个存储库同时成为一个活动的 Web 服务器（无论如何用于开发或测试/QA 环境）？
这就是我想要实现的：
更改将在开发上合并和测试，然后推送到测试/QA，依此类推。
顺便说一句，我们正在使用 Mercurial。我相信这个模型只能使用分布式源代码管理工具才能工作。
Why not have a repo also be an active web server (for dev or test/QA environment anyway)?
Here's what I am trying to implement:
Changes would be merged and tested on Dev, then pushed to Test/QA, and so on.
BTW, we're using Mercurial. I believe this model would only work using a distributed source code management tool.