Mercurial - 如何管理多个模块

时间:2013-01-03 08:57:04

标签: svn version-control mercurial

我在使用Subversion的团队中工作,我们正在考虑转换为Mercurial。

我们有多个独立代码的独立项目,以及一些项目之间共享的代码。为简单起见,假设有两个项目SpaceGameSeaGame都使用GraphicsEngine中的代码。 GraphicsEngine正在开发,有些独立于游戏。假设我们需要在几个月前将SpaceGame更新为修订版467; SpaceGame需要返回到第467版,GrpahicsEngine需要回到SpaceGame处于467时的修订版,GraphicsEngine无法保留最新版本。我们使用Subversion实现这一目标的唯一方法是我们将所有项目放入其中的一个大型存储库(外部代码不会向我们提供我们需要的行为)。这给我们的团队带来了很多问题;回购是巨大的,几乎没有人想要全面检查它,他们只检查他们需要的项目。

如何使用Mercurial处理这种情况?

2 个答案:

答案 0 :(得分:4)

这听起来像Mercurial subrepositories的用例。

这意味着您可以将GraphicsEngine作为子存储库放入SpaceGame (或者,如果您关注the recommended structure,请创建一个包含GraphicsEngineSpaceGame以及子存储库的精简“包装”存储库

子存储库的工作方式,SpaceGame并不总是包含最新版本的GraphicsEngine ...它指向某个固定版本,如果GraphicsEngine更新了与此同时,SpaceGame自动获取这些更改...您必须进行明确更新才能获得这些更改。
这意味着SpaceGame永远不会因为其他人对GraphicsEngine的更改而意外中断。

这也意味着(这就是您所询问的),当您从几个月前更新SpaceGame“到修订版467”时,GraphicsEngine子存储库{ {3}}


修改

不,GraphicsEngine仍然是一个单独的存储库,而不是任何人“拥有” 如果将其用作子存储库,则它只是从父存储库“链接”(并且可以从多个父存储库链接)。它仍然是一个单独的存储库。

对于子存储库,可以这样:

GraphicsEngine      // main GraphicsEngine repo, current revision: 300

SpaceGame           // main SpaceGame repo
  └ GraphicsEngine  // GraphicsEngine subrepo, current revision: 265

SeaGame             // main SeaGame repo
  └ GraphicsEngine  // GraphicsEngine subrepo, current revision: 241

SpaceGameSeaGame每个都有GraphicsEngine子参数 每个子参数“指向”GraphicsEngine的某个修订版(在我的示例中为265和241) GraphicsEngine中的开发仍在继续(GraphicsEngine处于转速300),但最近的更改在SpaceGameSeaGame中不可见,因为它们都指向较早的{{1}修改。

答案 1 :(得分:1)

请注意:克里斯蒂安是对的,但我建议至少尝试GuestRepo而不是Subrepo,作为对某些子插补限制和缺点的答案。

顺便说一句:

  

externals不会给我们提供我们需要的行为

是错误的答案,研究结果不好。您可以以两种不同的方式使用svn:externals,并且两者(通过一些手工)将为您提供所需的结果

Subrepo-like way

GraphicsEngine在定义中作为外部链接与固定版本相关联。每次,当您必须在“SuperRepository”(带外部存储库)中使用更多新版本时,您必须更新外部定义和提交父级项目。有了这样的硬连接,Superrepo总是对父母 - 外部人员进行了一系列修改。

免费链接,手动更新延时机中的外部设备

如果您不想担心在方案1中监视外部更新(在 singe externals 更新定义的情况下可以使用挂钩自动更新),您可以使用外部链接,链接到图形引擎的HEAD(不要在定义中使用修订版)来获取包含外部数据的目录(或通过某些脚本)更新目录的成本。我太懒了,所以 - 只写这里的工作流程

使用HEAD链接,对于过去主要仓库的修订版N,外部必须处于修订版M的状态,这是修订版N时链接仓库的最新版本。幸运的是,svn可以使用日期标准(不同形式)作为-r选项的参数。您只识别提交N的日期时间并更新外部dir(获取“混合修订工作副本”)

主回购中的

svn log -q -r N将提供类似

的内容
------------------------------------------------------------------------
r34 | lazybadger | 2012-03-24 12:28:12 +0600 (Сб, 24 мар 2012)
------------------------------------------------------------------------

暂时记住日期字段“2012-03-24 12:28:12 +0600”。

svn help up确认,我们可以使用date作为修订说明符

-r [--revision] ARG      : ARG (some commands also take ARG1:ARG2 range)
                             A revision argument can be one of:
                             ...       
                                '{' DATE '}'
                             ...

并在SVN-Book,“修订日期”一章中,我们会找到正确的格式(日期 - 时间 - TZ)案例

...
$ svn checkout -r {"2006-02-17 15:30 +0230"}
...
$ svn checkout -r {2006-02-17T15:30-04:00}
...
$ svn checkout -r {20060217T1530-0500}

第一种格式是我们的最佳选择(因为我们已经从svn日志中获得了它),因此 - 我们可以在WC中使用外部(仍未与主修订同步)

cd EXTERNAL-DIR
svn up -r {"2012-03-24 12:28:12 +0600"}

并且在主要修订(在我的样本中)为34时,在同一状态下获得外部,与过去一样,

PS svn log ...| gawk {...}可以轻松提取和存储基本修订的日期时间