svn - 适应 svn :externals usage for move to Mercurial

Question

我们在企业环境中有一个 svn 存储库结构，如下所示:

root
  libs
    shared_lib1
    shared_lib2
    private_lib
  public_code
  private_code

其中 public_code 是一个外部存储库，它是开源的，并且公司外部的人员具有读写访问权限。 shared_lib1 和 shared_lib2 也是与来自其他公司的不同程序员组共享的外部存储库。我是维护者，基本上可以做任何技术上最好的事情，外部用户将不得不适应。

我现在想知道从这种结构转移到 mercurial 存储库的最佳方法是什么。

1)我可以使用 mercurial 子存​​储库密切模拟旧设置。或者
2)我可以为我们创建一个大的存储库，为外部合作伙伴创建三个新的较小的独立存储库(因此基本上是 fork 项目)，并在大存储库和独立存储库之间交换变更集。

对于 svn 中的设置 1)，分支是一场噩梦，因为根据政策，当我分支 root 时，我总是必须分支 public_code、shared_lib1 和 shared_lib2。为此，我必须四次调用 svn branch 并手动修改 svn:externals 属性 3 次。我可以轻松地在 mercurial 中分支主存储库并自动为所有子存储库获取新分支吗？

当我进行设置 2) 时，repos 之间的文件系统会有所不同。例如。我将在 repo "root"中有 public_code/Makefile 但该文件在 repo "public_code"中将只是 "Makefile"。 Mercurial 是否仍然能够在存储库之间同步更改？工作流程会是什么样子？

Answer 1

With setup 1) in SVN, branching is a nightmare because I by policy always have to branch public_code, shared_lib1 and shared_lib2 when I branch root. For this I have to call svn branch four times and modify svn:externals properties by hand three times. Can I easily branch the main repo in Mercurial and get automatically new branches for all sub-repositories?

不，子存储库不能那样工作。顶级存储库中的命名分支不会自动传播到子存储库。如果您制作 1.x在您的代码中分支，那么不清楚 shared_lib1也应该有 1.x分支。事实上，它可能不应该与顶级代码分支同时分支，尤其是当该库被多个不同的顶级项目使用时。

When I do setup 2), the file system will be different between repos. E.g. I will have public_code/Makefile in repo root but the file will be just Makefile in repo public_code. Will Mercurial still be able to synchronize changes between the repos? How could the workflow look like?

不，如果您像这样创建存储库，则无法在存储库之间进行推拉。当它们来自同一个“母”存储库时，您只能在存储库之间推/拉。听起来您将创建三个不相关的存储库。

在这种情况下，您应该仔细评估为什么会出现 svn:externals在 Subversion 中以及它们如何映射到 Mercurial subrepositories .它们不是 svn:externals 的 1-1 替代品.您还应该查看对子仓库的工具支持——包括 Mercurial 本身和您的 Mercurial 托管、您的持续构建系统等。我编写了部分 Mercurial 子仓库代码，从 Mercurial 2.0 开始，这里和那里仍然有一些尖锐的边缘。

简而言之，子存储库给你的是一个 非常紧的耦合子系统之间。这通常是需要避免的 :-) 我们努力使我们的软件系统松散耦合，因为这给了我们灵活性。

子存储库的主要用例是“构建存储库”，您可以在其中跟踪在给定构建中使用的组件的精确版本。您不能要求 Mercurial 跟踪子存储库中给定分支的提示，它始终会跟踪给定存储库中的给定变更集。这使得以后可以重新创建给定的结帐: .hgsubstate文件跟踪在每个子仓库中 check out 的精确变更集。

所以如果你的 root存储库不用于开发，而仅用于构建版本，然后子存储库实际上可以为您工作。工作流程将类似于

$ cd root
$ cd libs/shared_lib1
$ hg pull
$ hg update 2.0
$ cd ../..
$ make test && hg commit -m "Updated to sharedlib1 2.0"
$ hg tag 2.3

然后您发布了软件的 2.3 版，Mercurial 知道它依赖于 shared_lib1 的 2.0 版。 .当负责子组件的人员告诉您他们为您准备好新版本时，您会偶尔这样做。您的 CI 服务器当然可以每晚执行此操作，以查看组件是否协同工作!

如果开发人员在 root 中工作，则子存储库的工作不太好。直接，如果他们在 root 中对子组件进行更改作为他们工作的一部分.这表明组件之间的耦合过于紧密:如果主代码依赖于子组件的精确变更集，那么子组件应该直接在主代码中。另外， hg commit当 ui.commitsubrepos=True 时，在顶级存储库中将递归并在子存储库中使用相同的提交消息。 . (默认值在 Mercurial 2.0 中更改为 False。)这通常是不希望的，当它确实有意义时，那么子存储库将非常紧密地耦 merge 且应该是顶级存储库的一部分。

所以，总结一下:如果 root 使用 subrepos是一个“构建存储库”。否则，您应该内联顶级存储库中的组件，或者您应该使用诸如 Maven 之类的东西将这些组件更松散地耦合在一起。或类似的管理依赖项。这些工具通常会让您说“请使用最新版本的 root 及其所有依赖项”，然后您可以在对测试感到满意时正式发布。这些“快照”构建无法精确复制，但这也不是必需的——只有最终版本需要严格和精确的依赖关系跟踪。