供应链管理中的依赖管理

Question

为了便于论证，假设我正在从事一个具有依赖性的项目，X，现在Y是一个独立的开源项目，由第三方定期维护和更新。我查看了Y的最新版本，将其提交到托管X的存储库，并且随着时间的推移，我可能会在本地回购中对Y进行更改。两个月后，我决定将开源回购的最新变化合并回我的，以获得最新的bug修复、特性等。如果这两个分支是同一个回购的一部分，这将是一个不需要思考的问题。我如何能够相对不痛苦地在Git、Mercurial和Subversion中进行交叉回购？

谢谢。

Answer 1

你是说你会在你的存储库里放一个Y的副本吗？如果是这样的话，对于您提到的任何一个VCS来说，这都不是正确的方法。您希望将Y的存储库“分叉”到Y- to中，在其中提交您的更改。然后，您可以在项目X中将构建系统的配置文件作为依赖项包含到存储库Y-‘s任何现代构建系统中的特定版本的指针。

这给了你最好的两个世界--你可以在你想要的时候从Y合并成Y-我的，而且你有精确版本的Y-我的存储在X中100%可重复的构建。

Git和Mercurial都有子回购系统，可以让你说“Z版的Y- or是回购X的一部分”，但它们比出租pip、maven、sbt、gem、visual或ivy2之类的东西要简单得多.处理依赖关系管理。

Answer 2

我对此的看法是，您可以看看Debian如何使用其Git打包工作流来使用工具。

该工具提供的工作流程与上游供应商使用的VCS无关，其组织方式(大致)如下：

• 您至少有两个分支：upstream和master。
• upstream保存(未经修改的)上游源的快照，通常是从上游供应商提供的发布tarball中获取的。也就是说，在这个分支上的每一次提交都是由以下步骤产生的：

1. The `upstream` branch is checked out.
2. All existing files are _deleted_ (`git rm -rf .`).
3. The new version of upstream sources is unwrapped and copied over to the work tree, and then added (`git add .`).
4. A new commit is then recorded (and a tag `upstream/vX.Y.Z` is created pointing to this commit).

​

• master包含upstream上的内容以及提供构建Debian包的基础设施的一组文件(实际上，这只是一个名为“debian”的目录)。 每次将新版本的上游源导入到upstream分支时，该分支将被合并到master中，然后包维护人员将其“去二进制化”进行主裁剪，以匹配由上游引入的更改。

我认为这种方法很可能适用于使用普通Git的情况：

• 维护这样一个“上游”分支(您可以称之为“供应商”或"that_framework“等等)。它应该只接收上游源的新版本(也可能是偶尔的上游补丁等等)。
• 在将上游源的新版本导入到该分支之后，将其合并到您的master (或您的工作流中更适合的分支)。

使用Mercurial和Subversion也可以使用它们各自的Git shims，但我怀疑(虽然不能完全确定)这会使事情复杂化，而不是简化。