Mercurial 和 VCS 新手：共享代码多服务器设置
在我们的小办公室里，我们正在设置 Mercurial - 我们第一次使用“真正的”版本控制系统。我们有三台服务器——一台实时服务器、一台临时服务器和一台开发服务器。
我们还有三个相对较大的网站 - 一个供访客使用，一个供用户使用，还有一个供办公室工作人员使用的内部网站点。
这三个网站共享一些代码。 （例如 - 一个php类库，一些常用的代码片段等）
在版本控制之前，我们只是使用符号链接来链接到共享库。例如：每个站点都有一个指向“ObjectClasses”目录的符号链接 - 对 ObjectClasses 中的文件所做的任何更改都将立即可供所有站点使用。您只需将更改后的文件上传到暂存并上线，就完成了。
但是... Mercurial 不遵循符号链接。因此，我在三台服务器上的三个站点中为共享库设置了一个子存储库（如果算上有两个程序员在开发服务器上拥有两个独立的存储库克隆，那么实际上是“四台”服务器）。
因此共享对象库有 12 个工作副本。
那么问题来了：
有什么办法可以简化上述设置吗？
下面是我们的工作流程的示例，它看起来太复杂了 - 但也许这就是使用版本控制的感觉，我们只需要习惯它：
程序员 A 对站点 1 的子存储库中的对象 Foo 进行了更改。他希望使其在任何地方都可用，因此他提交了它，然后将其推送到登台服务器。我在临时服务器上设置了挂钩，以自动将更改传播到临时服务器上的三个站点，然后再次传播到实时服务器上的三个站点。这会处理临时服务器和实时服务器上的 6 个工作副本。到目前为止，一切都很好。
但是开发服务器呢？这些文件可能正在进行中？
程序员 A 现在需要手动将共享子存储库拉取到开发服务器上的站点 2 和站点 3。他还需要告诉程序员 B 在开发服务器上的站点副本上手动拉取站点 1、2 和 3 上的共享子存储库。如果他在站点 1 上编辑对象 Foo，并在站点 2 上对对象 Foo 进行不同的编辑，该怎么办？他必须解决两个单独的冲突。
我们相对频繁地对对象进行更改。这会让我们发疯的。我真的很喜欢版本控制的想法 - 但经过两周的努力寻找最好的设置，旧的草率方式是拥有一份共享文件的副本并喊出“嘿 - 你正在处理该文件，我想让改变”现在看起来相当不错。
真的没有更简单的方法来设置吗？
In our small office we're setting up mercurial - our first time using a "real" version control system. We've got three servers - a live server, a staging server and a development server.
We've also got three relatively large web sites - one for visitors, one for users and an intranet site, for the office staff.
The three web sites share some code. (for instance - a php class library, some commonly used code snippets, etc.)
Before version control, we just used symbolic links to link to the shared libraries. For example: each site had a symbolic link to an "ObjectClasses" directory - any changes made to a file in ObjectClasses would be instantly available to all the sites. You'd just upload the changed file to staging and to live, and you were done.
But... Mercurial doesn't follow symbolic links. So I've set up a subrepository for the shared libraries in the three sites on the three servers (actually 'four' servers if you count the fact that there are two programmers with two separate clones of the repository on the development server).
So there are 12 working copies of the shared object library.
So here's the question:
Is there any way to simplify the above set up?
Here's an example of what our workflow will be and it seems too complicated - but maybe this is what it's like using version control and we just need to get used to it:
Programmer A makes a change to Object Foo in the subrepo in Site 1. He wants to make this available everywhere, so he commits it, then pushes it to the staging server. I set up hooks on the staging server to automatically propogate the changes to the three sites, on the staging server, and again to the three sites on the live server. That takes care of the 6 working copies on the staging and live servers. So far, so good.
but what about the development server, where there may be work-in-progress on these files?
Programmer A now needs to manually pull the shared subrepo to Sites 2 and 3 on the development server. He also needs to tell Programmer B to manually pull the shared subrepo on Sites 1, 2 and 3 on his copy of the site on the development server. What if he's editing Object Foo on Site 1 and making different edits to Object Foo on Site 2. He's going to have to resolve two separate conflicts.
We make changes to the objects relatively frequently. This is going to drive us nuts. I really love the idea of version control - but after two weeks of wrestling with trying to find the best setup, the old sloppy way of having one copy of the shared files and calling out "hey - ya working on that file, I wanna make a change" is looking pretty good right now.
Is there really no simpler way to set this up?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果没有有关您正在使用的特定 Web 平台和技术（例如 .NET、LAMP、ColdFusion 等）的更多信息，这个答案可能不够充分，但让我尝试一下。首先，如果我理解正确的话，问题出在你的工作模式上。您让开发人员对文件进行更改，然后将它们推送到三个不同的站点。我建议将开发问题与构建/部署问题完全分开。
听起来您正在使用 Mercurial 中的子存储库来处理共享代码——顺便说一句，这很聪明——所以这很好。这负责在多个项目之间共享代码。但是，与其让每个程序员在更新后将内容推送到给定的服务器，不如让程序员将内容推送到其他“暂存”存储库。如果您愿意，您可以为每台服务器都拥有一个，尽管我认为将所有开发保留在单个暂存或“主”存储库中可能更有意义，然后使用该存储库来构建/部署到您的暂存和/或实时服务器。
如果您希望自动化此过程，有许多工具可以做到这一点。我通常更喜欢 NAnt 与 CruiseControl 进行构建集成，但我的工作主要是 .NET，这使得它非常适合。如果您可以提供更多细节，如果您愿意，我可以提供更多详细信息，但我认为您需要克服的主要问题是处理工作流程的方式。使用 Mercurial 可以让多个开发人员乐于从单个存储库拉/推，然后再担心将其部署到服务器以作为单独的步骤进行测试。
Without more information about the specific web platform and technologies you're using (e.g., .NET, LAMP, ColdFusion, etc.), this answer may be inadequate, but let me take a stab nevertheless. First, if I understand you correctly, it's your working paradigm that's the problem. You're having developers make changes to files and then push them to three different sites. I suggest separating the development concerns altogether from the build/deploy concerns.
It sounds like you're using subrepositories in Mercurial to handle shared code--which is smart, by the way--so that's good. That takes care of sharing code across multiple projects. But rather than have each programmer pushing stuff to a given server after he updates it, have the programmers instead be pushing to some other "staging" repository. You could have one for each of your servers if you wish, though I think it probably makes more sense to keep all development in a single staging or "master" repository which is then used to build/deploy to your staging and/or live server.
If you wish to automate this process, there are a number of tools that can do this. I usually prefer NAnt with CruiseControl for build integration, but then my work is mostly .NET which makes it a great fit. If you can provide more specifics I can provide more details if you like, but I think the main problem for you to overcome is the way you're handling the workflow. Use Mercurial to keep multiple developers happy pulling/pushing from a single repository and then worry about deploying to your servers for testing as a separate step.