svn - 多个分支的 Mercurial 存储库布局

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




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

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

对于这个玩具示例，其他 SVN 布局自然是可能的，但这种布局具有优势:

我可以在保留历史记录的同时在分支之间复制文件

我只能 checkout 项目的一个子集，例如 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 功能允许 checkout 子目录。子目录功能是 Mercurial 团队关心的功能之一，但它也不是微不足道的，这就是尚未完成的原因。不过我知道 Mercurial 的内部结构，这绝对是可行的，只是做了很多工作。

第二个最好的选择，虽然我认为它真的很丑，但你提到的命名分支的想法。但是，只要您想在分支之间复制文件，您仍然需要执行一个非常奇怪的 merge 操作。您将执行以下步骤:

更新到要将文件复制到的分支的负责人:hg update -C project1

merge 您要从中复制文件的分支:HGMERGE=/bin/false hg merge -r project2

恢复到要将文件复制到的分支的头部:hg revert -a --no-backup -r project1

从 merge 分支的主修订中恢复要复制的特定文件:hg revert --no-backup -r project2 path/to/file/in/project2.txt

将文件移动到要复制到的分支中的位置:hg mv path/to/file/in/project2.txt project1/file/path/project2.txt

将 merge 标记为已解决:hg resolve -am

最后提交结果:hg commit -m "A merge to copy project2.txt to project1."

正如我所说，非常丑陋。而且它可能只在 hg 1.3 中运行良好，因为我知道最近修复了恢复、 merge 和解析交互中的一些重要错误。 (恕我直言，我怀疑 Ubuntu 故意落后于非 bzr 版本控制系统的版本。)

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

我已经在 Subversion 中为我自己的几个项目做了类似的事情，但我的经验是，我对某个项目真正属于哪个项目的最初感觉通常是正确的，并且当它不保存历史时并没有那么大一笔交易，因为历史实际上只与文件所在的原始项目相关。