mercurial和VCS的新功能:共享代码多服务器设置

时间:2011-06-21 15:17:18

标签: version-control mercurial shared subrepos mercurial-subrepos

在我们的小办公室,我们正在设置mercurial - 我们第一次使用“真正的”版本控制系统。我们有三台服务器 - 一台实时服务器,一台临时服务器和一台开发服务器。

我们还有三个相对较大的网站 - 一个用于访问者,一个用于用户,一个内部网站点,用于办公室工作人员。

三个网站共享一些代码。 (例如 - 一个php类库,一些常用的代码片段等)。

在版本控制之前,我们只使用符号链接链接到共享库。例如:每个站点都有一个指向“ObjectClasses”目录的符号链接 - 对ObjectClasses中的文件所做的任何更改都将立即提供给所有站点。您只需将更改的文件上传到暂存和生活,就完成了。

但...... Mercurial没有遵循符号链接。所以我已经为三台服务器上的三个站点中的共享库建立了一个子存储库(实际上是'四个'服务器,如果你算上有两个程序员在开发服务器上有两个独立的存储库克隆)。 / p>

因此共享对象库有12个工作副本。

所以这就是问题:

有没有办法简化上面的设置?

以下是我们工作流程的一个示例,它看起来太复杂了 - 但也许这就像使用版本控制一样,我们只需要习惯它:

程序员A在Site 1的subrepo中对Object Foo进行了更改。他想让它在任何地方都可用,所以他提交它,然后将它推送到登台服务器。我在登台服务器上设置了挂钩,以自动将登录服务器上三个站点的更改传播到实时服务器上的三个站点。这将处理登台和实时服务器上的6个工作副本。到目前为止,非常好。

但是开发服务器怎么样?这些文件可能正在进行中?

程序员A现在需要手动将共享子目录拉到开发服务器上的站点2和3。他还需要告诉程序员B在开发服务器上的站点副本上手动拉出站点1,2和3上的共享子站点。如果他正在编辑Site 1上的Object Foo并对Site 2上的Object Foo进行不同的编辑,那么他将不得不解决两个不同的冲突。

我们相对频繁地更改对象。这将使我们疯狂。我真的很喜欢版本控制的想法 - 但经过两周的努力试图找到最好的设置,旧的草率的方式有一份共享文件,并呼吁“嘿 - 你在那个文件上工作,我想做改变“现在看起来很不错。

真的没有更简单的方法来设置它吗?

1 个答案:

答案 0 :(得分:0)

如果没有关于您正在使用的特定网络平台和技术的更多信息(例如,.NET,LAMP,ColdFusion等),这个答案可能不充分,但让我采取措施。首先,如果我理解正确,那就是你的工作范式就是问题所在。您正在让开发人员对文件进行更改,然后将其推送到三个不同的站点。我建议将开发问题完全从构建/部署问题中分离出来。

听起来你在Mercurial中使用子存储库来处理共享代码 - 顺便说一句,这很聪明 - 所以这很好。这需要跨多个项目共享代码。但是,不是让每个程序员在更新它之后将东西推送到给定服务器,而是让程序员推送到其他一些“临时”存储库。如果您愿意,您可以为每个服务器配备一个,但我认为将所有开发保留在单个暂存或“主”存储库中可能更有意义,然后将其用于构建/部署到您的暂存和/或实时服务器

如果您希望自动执行此过程,可以使用许多工具来执行此操作。我通常更喜欢使用CruntControl的NAnt进行构建集成,但后来我的工作主要是.NET,这使它非常适合。如果您可以提供更多细节,我可以提供更多详细信息,但我认为您需要克服的主要问题是您处理工作流程的方式。使用Mercurial可以让多个开发人员从单个存储库中快速提取/推送,然后担心部署到服务器以便作为单独的步骤进行测试。