多个分支的Mercurial存储库布局

Question

我有许多准相关项目，我想进行版本控制。在SVN中，我将它们设置为单个项目中的多个目录

/scripts  #updates in sync with project1 & project2
/project1 #requires database
/project2 #requires database
/database

当然，这个玩具示例可以使用其他SVN布局，但这种布局具有以下优势：

• 我可以在保留历史记录的同时在分支机构之间复制文件
• 我只能查看一部分项目，例如svn co repo/project2; svn co repo/database。 这节省了大量的存储空间。如果project1很大，则为时间。
• 轻松进行存储库管理，因为所有项目都定义了一次用户访问权

自you can't clone a single directory of a mercurial repo以来，这种范式不能很好地映射到mercurial。所以我的问题是：在mercurial中存储大型密切相关项目的最常用方法是什么？

我的想法：

• 多个存储库 - 丢失在项目之间移动的文件的历史记录
• Forests - 似乎停滞不前，我不确定此扩展程序的稳定性
• 主要与内容无关的命名分支
• SubRepos - 不幸的是我正在运行Ubuntu 9.04，它只运送hg 1.1.2。否则这看起来是个不错的选择

Answer 1

多个存储库，Forests和SubRepos都是同一个想法的变体。 Forests和SubRepos只是使管理项目更容易使用最新版本的其他项目，它们无法解决您遇到的基本问题，即在项目之间移动时丢失文件历史记录。

在我看来，最好的办法是将所有目录放在同一个存储库中，等待Mercurial功能允许签出子目录。子目录功能是Mercurial团队所关注的功能，但要做到这一点并非易事，这就是为什么还没有完成的原因。我知道Mercurial的内部结构，这绝对可行，只需要做很多工作。

第二个最好的选择，虽然我认为它真的很丑，但是你提到的命名分支机构的想法。尽管你想在分支机构之间复制文件，你仍然会有一个非常奇怪的合并操作。您将执行以下步骤：

1. 更新要将文件复制到hg update -C project1
的分支的负责人
2. 合并您要复制文件的分支：HGMERGE=/bin/false hg merge -r project2
3. 恢复到要将文件复制到的分支的头部：hg revert -a --no-backup -r project1
4. 从合并分支的主版修订版中还原您要复制的特定文件：hg revert --no-backup -r project2 path/to/file/in/project2.txt
5. 将文件移动到要将其复制到的分支中的位置：hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
6. 将合并标记为已解决：hg resolve -am
7. 最后提交结果：hg commit -m "A merge to copy project2.txt to project1."

正如我所说，非常难看。它可能只适用于hg 1.3，因为我知道恢复，合并和解决的交互中的一些重要错误最近才被修复。 （恕我直言，我怀疑Ubuntu是故意支持非bzr版本控制系统的版本。）

您真的希望在项目之间复制文件的频率是多少？为什么会这样？你确定失去历史会是一件坏事吗？

我在Subversion中为自己的几个项目做了类似的事情，但我的经验是，我最初对某个项目真正属于哪个项目的感觉通常是正确的，当它不保存历史时不是真的那么大，因为历史真的只与原始项目有关，无论如何。