SCM中的依赖管理

Question

为了论证，让我说我正在开发一个项目，X，它有一个依赖项，Y.现在Y是一个独立的开源项目，由第三方定期维护和更新。我查看了Y的最新版本，将其提交给托管X的存储库，随着时间的推移，我可能会在本地仓库中对Y进行更改。两个月后，我决定将开源代码库中的最新更改合并到我的内容中，以获取最新的错误修复，功能等。如果这两个分支是同一个回购的一部分，这将是一个没有脑子的。我如何[相对]无痛地在Git，Mercurial和Subversion中进行这种交叉回购合并？

感谢。

Answer 1

你是说你在X的存储库中放了Y的副本？如果是这样，那么对于您提到的任何VCS来说，这都不是正确的方法。您想要将Y的存储库“分叉”到Y-mine中，您可以在其中提交更改。然后，项目X中的构建系统的配置文件包含作为依赖项的指向存储库Y-mine中特定修订的指针 - 任何现代构建系统都会这样做。

这为您提供了两全其美的优势 - 您可以随时从Y合并到Y-mine中，并且您可以在X中存储Y-mine的确切版本，以获得100％可重复的构建。

Git和Mercurial都有subrepo系统，允许你说“Y版本Z版是回购X的一部分”，但它们比让pip或maven或sbt或gem或visual studio或ivy2或其他任何东西更笨拙...处理依赖关系管理。

Answer 2

我的看法是，您可以查看Debian使用git-buildpackage tool的Git打包工作流程所做的工作。

此工具提供的工作流程与上游供应商使用的VCS无关，并且（大致）组织如下：

• 您（至少）有两个分支：upstream和master。

• upstream包含（未修改的）上游源的快照，通常来自上游供应商提供的发布tarball。也就是说，此分支上的每个提交都来自以下步骤：

  1. 检出upstream分支。
  2. 所有现有文件已删除（git rm -rf .）。
  3. 将新版本的上游源解包并复制到工作树，然后添加（git add .）。
  4. 然后记录新的提交（并创建一个指向此提交的标记upstream/vX.Y.Z。）

• master包含upstream上的内容以及一组提供构建Debian软件包的基础结构的文件（实际上，这只是一个名为“debian”的目录）。

  每次将新版本的上游源导入upstream分支时，该分支将合并到master中，然后包维护者会根据主人的需要定制他们的“debianization”以匹配更改上游介绍。

我认为这种方法很可能在你的情况下使用普通的Git：

• 维护这样一个“上游”分支（您可以将其称为“供应商”或“that_framework”等）。它应该只接收上游源的新版本（也可能偶尔会出现上游补丁等）。
• 将新版本的上游源导入该分支后，将其合并到您的master（或任何适合您工作流程的分支）。

使用Mercurial和Subversion也可以使用他们各自的Git填充程序，但我怀疑（虽然不完全确定）这会使问题变得复杂，而不是简化。