人们如何管理对存储在多个（Mercurial）存储库中的公共库文件的更改？答案

【问题标题】：How do people manage changes to common library files stored across mutiple (Mercurial) repositories?人们如何管理对存储在多个（Mercurial）存储库中的公共库文件的更改？
【发布时间】：2009-12-30 17:48:45
【问题描述】：

这可能不是 Mercurial 独有的问题，但这是我最近使用最多的 SCM。

我从事多个项目，并倾向于从以前的项目中复制库或实用程序的源代码，以便在开始新项目时占得先机。当我想将我在最新项目中所做的所有更改合并回这些共享库文件的“主”副本时，问题就出现了。

由于存储在不相交存储库中的文件将具有不同的版本历史记录，如果我只是将文件复制回主存储库（甚至在两个独立项目之间），Mercurial 将无法执行智能合并。

我正在寻找一种简单的方法来保留更改历史记录，这样我就可以将库文件合并回主文件，同时保留最少的外部记录（这是我使用 SVN 较少的原因之一，因为合并需要记住跨分支复制时）。

也许我需要对我的存储库做更多的前期组织，以便为将来合并回一个共同的主库做准备。

【问题讨论】：

标签： version-control mercurial merge

【解决方案1】：

三种解决方案，选择你喜欢的：

将所有项目放入一个存储库中。
为共享代码创建一个单独的存储库，并为每个项目创建不同的存储库。
一个包含子存储库的存储库：https://www.mercurial-scm.org/wiki/subrepos，将所有通用代码保存在一个子存储库中，并为每个项目保留不同的子存储库。

在没有共同祖先的存储库之间复制实际文件永远不会是最佳的，因为历史不会被保留。

【讨论】：

感谢您的快速回复。 1. 不实用 - 使用这些不同存储库的成员（人）是不同的。 2. 我想要一个包含每个项目所需的所有代码的存储库。这似乎排除了 2. 3. 我看到了这个“实验性”功能——人们真的在使用它吗？它稳定/推荐吗？这似乎是一个常见的问题，我希望我缺少一些标准做法。
Subrepos 用于生产。
在 1.3 中是实验性的，当前版本是 1.4.x

【解决方案2】：

我建议不要使用“复制源代码”的做法，而是为自定义库使用二进制分发。这些二进制文件在源代码中签入。

减少构建时间
无需跟踪库的所有副本中的更改的开销
您可以在不同的项目中使用同一库的不同版本。

编辑：对于“通用”或“工具箱”库的一般问题，请阅读 ayende 的 this post。

【讨论】：

就我而言，这是最好的解决方案。让您的持续集成构建系统每天（或在每次更改或其他任何情况后）创建一个新版本的通用代码，并让您使用库的项目直接从构建框下载/在构建脚本中使用它们。在内部我/我们使用'ivy'（我们是一家java商店）来简单地列出我们的内部和外部依赖项，它为我们省去了各种麻烦。
我认为这对我来说效果不佳，因为它把项目耦合得太紧密了。请注意，在分发库之前，您需要在所有使用这些库的项目中运行所有单元测试，以便安全地执行此操作。
对不起，我不明白。为什么要耦合项目？我的观点之一是能够为不同的项目使用不同的版本。分发时运行所有单元测试？如果使用源分发有什么不同？
我建议不要将二进制文件签入与源代码相同的存储库。尤其是使用 Mercurial，您正在为下载 repo 的每个人添加二进制文件。

【解决方案3】：

使用移植扩展

【讨论】：

呸。然后你会在所有地方都有相同的变化，但哈希值不同（由于它们的父母不同）。