调整 svn:externals 使用以迁移到 Mercurial [英] Adapting svn:externals usage for move to Mercurial

问题描述

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

We've got in a corporate environment an svn repository structure which looks like this:

root
  libs
    shared_lib1
    shared_lib2
    private_lib
  public_code
  private_code

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

where public_code is an external repository which is open source and where people from outside the company have read-write-access. shared_lib1 and shared_lib2 are also external repositories shared with a different group of programmers from an other company. I'm the maintainer and can do basically whatever is technically best, the outside users will have to adapt.

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

I'm now wondering what the best way is to move from this structure to a mercurial repository.

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

1) I could closely simulate the old setup using mercurial subrepositories. OR
2) I could make one big repo for us and three new smaller, separate repositories for the external partners (so basically forking projects) and exchange changesets between the big one and the separate ones.

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

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?

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

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 中的设置 1)，分支是一场噩梦，因为根据政策，我总是必须分支 public_code、shared_lib1 和 shared_lib2分支 root.为此，我必须四次调用 svn branch 并手动修改 svn:externals 属性 3 次.我可以轻松地在 Mercurial 中对主存储库进行分支并自动为所有子存储库获取新分支吗?

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 分支.事实上，它可能不应该与顶级代码分支同时分支，尤其是当该库被多个不同的顶级项目使用时.

No, subrepositories don't work like that. Named branches in the top-level repository will not propagate to subrepositories automatically. If you make a 1.x branch in your code, then it's not clear that shared_lib1 should also have 1.x branch. In fact, it probably shouldn't branch at the same time the top-level code branches, especially if the library is being used by several different top-level projects.

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

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?

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

No, you cannot push and pull between the repositories if you create them like that. You can only push/pull between repositories when they originate from the same "mother" repository. Here it sounds like you'll create three unrelated repositories.

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

In a situation like this, you should evaluate carefully why you have svn:externals in Subversion and how they map to Mercurial subrepositories. They are not a 1–1 replacement for svn:externals. You should also look into tool support for subrepos — both in Mercurial itself and your Mercurial hosting, your continues build system, etc. I wrote part of the Mercurial subrepo code and as of Mercurial 2.0, there are still some sharp edges here and there.

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

In a nutshell, what subrepositories give you is a very tight coupling between subsystems. This is normally something to be avoided :-) We try hard to make our software systems loosely coupled since that gives us flexibility.

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

The main use case for subrepositories is a "build repository" where you track the precise versions of your components that you used in a given build. You cannot ask Mercurial to track the tip of a given branch in a subrepo, it will always track a given changeset in a given repository. This is what makes it possible to re-create a given checkout later: the .hgsubstate file tracks the precise changesets that were checked out in each subrepo.

因此，如果您的 root 存储库不用于开发，而仅用于构建版本，那么子存储库实际上可以很好地为您工作.工作流程将类似于

So if your root repository is not used for development, but only for building releases, then subrepositories can in fact work great for you. The workflow will be something like

$ 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 服务器当然可以每晚执行此操作，以查看组件是否协同工作！

You then release version 2.3 of your software and Mercurial knows that it depends on version 2.0 of shared_lib1. You'll do this once in a while when the people responsible for the subcomponents tell you that they have a new release ready for you. Your CI server can of course do this nightly to see if the components work together!

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

Subrepositories work less well if the developers are working in root directly and if they make changes to the subcomponents as part of their work in root. That is an indication of a too tight coupling between the components: if main code depends on an exact changeset of a subcomponent, well then the subcomponent ought to be directly in the main code. Also, hg commit in the top-level repository will recurse and use the same commit message in the subrepos when ui.commitsubrepos=True. (The default was changed to False in Mercurial 2.0.) This is often not desired and when it does make sense, well then the subrepo to very tightly coupled and should be a part of the top-level repo.

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

So, to sum up: use subrepos if root is a "build repository". Otherwise, you should either inline the components in the top-level repository, or you should couple the pieces together more loosely by using something like Maven or similar to manage dependencies. These tools will normally let you say "please the latest version of root and all its dependencies" and then you can make a formal release when you're happy with the tests. These "snapshot" builds cannot be precisely reproduced, but that's also not needed — only the final releases need the strict and precise dependency tracking.

这篇关于调整 svn:externals 使用以迁移到 Mercurial的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！