因新见解而更新：五年后看到这个问题后，我意识到这源于尝试将版本控制系统用作包管理器。这当然会导致各种意想不到的问题，我们不应该这样使用它。如果您正在阅读此问题，我建议您搜索首选语言的包管理器。
我原来的问题：我目前正在从Subversion迁移到Mercurial，我不得不说我不后悔这个决定。但是，在尝试转换我的项目时，我遇到了Mercurial的问题，我似乎无法解决这个问题。我有两个不同的项目：一个是框架，另一个是依赖于该框架的应用程序。这是存储库的样子：
框架存储库：
应用程序存储库：
我想要的是应用程序的lib目录包含框架的lib /目录的副本。我曾经使用svn：externals这样做。现在，我知道Mercurial支持concept of subrepositories，但这似乎不是“正确的”解决方案，因为它实际上并没有像我想的那样拉入lib /目录，因为你仍然会有拉动并推送更改手动。这一点，加上克隆框架存储库后，你将获得所有，而不仅仅是lib /目录。我只需要lib /目录，而不是测试或文档。
现在，我想出了两个不同的解决方案来解决这个问题，但我想知道哪个是最好的。第一个解决方案是将框架完全克隆到不同的目录中，并在应用程序的lib /目录中创建符号链接，该目录指向框架的lib /目录。将符号链接放在.hgignore应该确保一切正常，我想？这意味着你可以编辑框架代码并提交它，你也可以编辑应用程序的代码并提交它。
另一种选择是拥有多个存储库。框架作为一个整体被拉出，这意味着你将获得docs /，deploy /，test / etc.目录，这些是框架的用途所不需要的。我想也许创建一个纯粹用于库的存储库可能是一个解决方案，虽然我真诚地怀疑它，因为单元测试非常依赖于库本身。
有没有人知道这个问题的合适解决方案？
答案 0 :(得分：2)
如果您只需要参考，那么您应该将库分离到一个单独的存储库中。
如果你实际做只需要参考那个。引用包含lib目录和其他东西的存储库有什么问题，除了“它感觉不对”？
至于“仍然必须手动拉动”，当你拉出主克隆时，它也会拉出子版本，但它不会将它们更新为更新版本，这是一件好事，你需要手动完成，就像你应该使用Subversion一样。
答案 1 :(得分：2)
您应该在自己的存储库中放置单独的组件。然后，当您创建应用程序时，可以使用convert extension创建一个超常规的pullabale框架库：
$ hg convert --filemap map.txt framework new-framework
使用包含renames / includes / excludes的map.txt（以下一个应该只包含lib目录并将其中的所有内容移动到存储库根目录）：
include lib
rename lib .
从应用程序存储库中，您现在可以拉动框架存储库（第一次使用-f，因为存储库可能与彼此无关）。
$ cd project
$ hg pull -f ../new-framwork
$ hg merge
现在，当开发进行时，你只需要在每次拉动之前重新创建转换后的回购，然后你就可以开始了。我们的框架存储库实际上有一个hook，可以在每个更改组上重新创建转换后的repo（=每次推送）。
通过这种方式，您可以在自己的存储库中同时拥有工作区域（应用程序和框架），而app repo包含完整的框架历史记录，只需从转换后的仓库中提取即可进行更新。