【问题标题】:Keeping third-party libraries under a Mercurial project: Sub-repos or not?将第三方库保存在 Mercurial 项目下:是否有子存储库?
【发布时间】:2010-06-13 09:41:54
【问题描述】:

我们正在开发一个使用 Mercurial 进行版本控制的闭源项目。我们在项目中使用了两个库:

  • 其中一个库正在由第三方开发。他们正在使用 git,我们通常每周从他们的 repo 中提取一次以获取最新的更改。

  • 其他库正在自行开发,正在积极开发中。它必须存在于自己的公共 mercurial 存储库中,因为它是在 LGPL 下获得许可的。 (它是第三方 LGPL 组件的一个分支,移植到我们的平台)

所以我的问题是:我应该如何组织来源以确保:

  1. 我们团队的开发人员应该能够通过一个“克隆”命令获取所有源代码(主项目 + 库)

  2. 我们应该能够轻松地从库中提取最新的更改,即使其中一个是由 git 管理的

我们应该使用 mercurial sub-repos 功能,用 hg-git 访问 git 下的库吗? TortoiseHg 和 BitBucket 是否很好地支持它? (优点:易于拉库更改/缺点:效果好吗?)

或者我们应该只保留项目下库的快照吗? (因此,当库中有新的上游更改时,我们将它们拉到一个单独的地方,然后将整个源代码复制到我们的项目中?(优点:会工作/缺点:很痛苦,特别是对于由我们自己开发,每天都会发生很多变化)

【问题讨论】:

    标签: mercurial subrepos


    【解决方案1】:

    是的,将 subrepo 与 hg-git 一起使用。它简单、支持良好且有效。您的.hgsubstate 文件将包含指向子存储库快照的指针,并且该文件是受控的,因此在任何时候您都可以回答这个问题:这是针对哪个版本的库 X 工作的。这是好东西。

    或者,您可以使用适合您的语言的依赖项管理器,例如 ivy 或 maven,但如果可以避免,请不要将它们的库包含在您的 repo 中。指向他们代码版本的指针更好,依赖管理器或子存储库是最干净的方法。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多