hoc*_*chl 5 merge mercurial repository
我刚刚根据这里给出的建议合并了两个存储库.由于两个存储库完全不相关,我使用
hg convert --filemap fm rep1a rep1b
hg convert --filemap fm rep2a rep2b
将存储库1中的文件移动到子目录a,将文件从存储库2移动到子目录b.现在两个存储库中没有冲突的文件,所以我将它们组合在一起.
结果是一个存储库,其中包含两个父项的合并修订,一个包含存储库1的历史记录,另一个包含存储库2的历史记录.很好!
mb--ma--2f--2e--2d--2c--2b--2a
\
-------------------------1e--1d--1c--1b--1a
现在我真正想要的是补丁按时间排序的历史.这没问题,我使用了hg convert --datesort src dst,一切看起来都不错:
mb--ma--2f------2e--2d------2c--2b--2a
\
-----1e----------1d--------------1c--1b--1a
我现在想要的最后一件事是所有补丁都被合并,以便它们具有线性依赖图,有效地消除了合并修订版"ma".我认为解决方案是对一些修订进行修改,但我缺乏理解哪个版本需要重新修改.我试验了一些,但似乎没有像预期的那样工作.一次尝试就产生了一些奇怪的问题:
use (c)hanged version or (d)elete?
我怎么能做最后一步？
编辑:我部分解决了这个问题.由于rebase似乎搞砸了(或者我没有完全理解问题是什么),一个不同的approch似乎工作得更好(正如Lasse所建议的):重写历史.
我所做的是将存储库再次拆分为原始的两个部分,使用hg convert with filemap,直到合并修订版.然后我使用hg移植将一个存储库移植到另一个存储库中.瞧,线性历史!
2f--2e--2d--2c--2b--2a--1e--1d--1c--1b--1a
在此之后,我移植了我在合并之后做的更改集.结果:实际工作副本与具有两个历史时间轴的备份没有差异.到现在为止还挺好!
mb--2f--2e--2d--2c--2b--2a--1e--1d--1c--1b--1a
现在修订版没有按时间排序,这是理想的,所以我尝试了一个hg convert --datesort repository.src repository.sorted,但结果仍然具有相同顺序的变更集,如上所示.如果有人知道如何做到这一点,我可以手工分类.
编辑2:我终于解决了这个问题,我创建了一个新的存储库
mkdir repository_c
cd repository_c
hg init .
我按正确顺序拉入所有补丁,使用hg transplant:
hg transplant --source ../src 0:53
hg transplant --source ../src 70
hg transplant --source ../src 54:55
hg transplant --source ../src 71:79
hg transplant --source ../src 55:60
...
这完成了工作,历史是线性的,补丁按正确的顺序排序.由于没有冲突的补丁,并且头版本与具有两个时间轴的原始存储库相同,我很高兴.我确实使用MQ扩展来为所有修订创建补丁文件列表并手动控制它们,但从我可以看出历史是完美的.
合并不相关的历史记录效果不佳，因为每个变更集都是项目在某种状态下的快照。如果您只是简单地使用 pull -f 或使用 Convert 进行移植，您将获得一个具有明显不相关历史记录的存储库。您不会得到一个整洁的历史记录，显示嫁接的历史记录被添加到主项目中，就像您想要的那样一次提交。相反，您将获得一堆仅包含来自项目 A 的文件的提交，以及一堆仅包含来自项目 B 的文件的提交。简而言之，这是因为“事情实际上并没有那样发生”。将历史图表拼接在一起并不能修复这些变更集的内容。
因此，唯一可用的答案是在项目 A 的目录命名空间的正确部分，一次一次提交一次实际重放项目 B 的历史记录。这可以通过 hg export + import “手动”完成，也可以通过 hg Convert --filemap 和移植或变基的某种组合来完成。
我已经调整了您提到的维基页面以弃用该“建议”。一般来说，我根本不建议尝试做这类事情，同样是因为“实际上并没有那样发生”。最好在一次提交中提取项目 B 的整个历史记录，并在提交消息中提供指向其真实历史记录的指针。