如何将大型 Mercurial 存储库分解为较小的存储库
这是此问题的重复项，，但具体涉及 Mercurial 。
我有一个巨大的颠覆存储库，我已将其转换为 Mercurial。现在看起来像这样：
MassiveFolder/
.hg/
bin/
common/
projA/
projB/
...
projX/
makefile
README
我希望每个子项目都在自己的存储库中进行跟踪，以获得更好的性能。请注意，它们都构建到同一个 bin 文件夹中。我认为这不会成为问题，但我不确定是否需要做任何事情来调整路径。可以安全地假设每个开发人员都会以相同的结构克隆存储库，但如果有某种方法可以创建一个可以确保这一点的元存储库，那就更好了。
有这样做的标准方法吗？我应该如何处理根文件夹中的 makefile 和自述文件等文件？
如果我必须通过其他一些过程重新开始导入 hg ，那也不应该成为问题。尽管它已经让 svn 脱颖而出，但使用整体存储库执行标准操作需要太长的时间。
This is a duplicate of this question, but specpifically regarding mercurial.
I have a massive subversion repository that I have converted to mercurial. It now looks like this:
MassiveFolder/
.hg/
bin/
common/
projA/
projB/
...
projX/
makefile
README
I would like each subproject to be tracked in its own repository for better performance. Notice that they all build into the same bin folder. I don't think that will be a problem, but I am not sure if I will need to do anything to adjust the paths. It is safe to assume each developer will clone the repositories in the same structure, but if there was some way to make a meta-repository that can ensure that, it would be even better.
Is there a standard way of doing this? What should I do about files like the makefile and the readme that live in the root folder?
If I have to start over importing to hg through some other process that shouldn't be a problem either. It just takes far too long to do standard operations with he monolithic repository, even though it already blows svn out of the water.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以使用 Mercurial 的 转换扩展 （自从您将存储库从SVN 到 HG) 以及
-filemap选项为 SVN 子文件夹创建单独的 HG 存储库。您特别需要
include指令：然后，您可以使用 Mercurial Subrepositories 在所需的文件夹结构中设置存储库：
You can use Mercurial's Convert Extension (which you probably already know since you converted the repository from SVN to HG) with the
-filemapoption to create separate HG repositories for the SVN subfolders.You need the
includedirective in particular:Then, you could use Mercurial Subrepositories to set up the repositories in the desired folder structure:
我在较小的存储库上成功使用的方法如下：
确定列出较小的存储库以及它们如何相互关联。
hg rm所有您不需要的文件如果子项目与顶级 Makefile 交织在一起，您可以添加一个顶级存储库，其中的子存储库位于较小的存储库中。
这种方法保留了历史，并且不强迫人们重新克隆。如果您可以接受爆炸历史记录，那么转换就可以了，并且会缩小存储库的大小。
一句（或几句）警告：与单一存储库操作的简便性相比，子存储库有很多困难的行为。有些操作会递归，有些则不会。合并尤其是递归，这经常让我感到不舒服。确定整个系统状态可能具有挑战性，尤其是随着子存储库数量的增加（我正在帮助管理一个具有超过 100 个子存储库的项目，是的，这是处理问题的逻辑和最佳方法它）。
My approach - which I have used successfully on smaller repositories is as follows:
Determine list smaller repositories and how they will interrelate.
hg rmall files you do not wantIf the subprojects are intertwined with a top-level Makefile, you can add a top-level repository which subrepositories in the smaller repositories.
This approach maintains history and does not force people to reclone. If you are okay with exploding history, convert is fine, and will shrink repository size.
A word (or a few) of warning: subrepositories have a good deal of difficult behavior as compared to the ease of one-repository operations. Some operations recurse, other's don't. Merge in particular recurses, which routinely gives me fits. Determining the entire system state can be challenging, especially as the number of subrepositories goes up (I'm helping manage a project with > 100 subrepositories, and yes, that was the logical and best way to handle it).