将Mercurial存储库分为两个独立的存储库_Mercurial_Version Control

将Mercurial存储库分为两个独立的存储库

mercurial version-control

将Mercurial存储库分为两个独立的存储库,mercurial,version-control,Mercurial,Version Control,和许多人一样，我有几个SVN存储库，其中包含几个项目。出于几个原因，我决定将其中一个存储库转换为Mercurial 我已使用成功地转换了存储库。新的hg回购协议包括一切；所有历史记录和正确的标签。这种转变非常有效现在，我需要“分化”这两个项目，但我想保持双方的历史。我想知道是否有一种方法可以适当地做到这一点，以防止类似意外地将变更集导入其他存储库这样的事情明确地说，我不在乎每个存储库对于当前的更改是否都有相同的历史记录（事实上，我希望这样）。我只是想指出，从现在起，它们是“不同”的存储库更

和许多人一样，我有几个SVN存储库，其中包含几个项目。出于几个原因，我决定将其中一个存储库转换为Mercurial

我已使用成功地转换了存储库。新的hg回购协议包括一切；所有历史记录和正确的标签。这种转变非常有效

现在，我需要“分化”这两个项目，但我想保持双方的历史。我想知道是否有一种方法可以适当地做到这一点，以防止类似意外地将变更集导入其他存储库这样的事情

明确地说，我不在乎每个存储库对于当前的更改是否都有相同的历史记录（事实上，我希望这样）。我只是想指出，从现在起，它们是“不同”的存储库

更新：有人能详细介绍一下--force吗？在什么情况下需要使用该标志。在“pull”下，我看到-f，-force选项是“即使远程存储库不相关也运行”，但是什么使存储库不相关呢？对我来说，因为我是从原始存储库克隆的，所以它们（或者可能）是相关的
更新：我试图阻止的是，在一段时间后，允许一个回购协议被拉入另一个回购协议。（现在是这样）我写了一个脚本产生了这个问题。并且完全实现了我不希望发生的事情（这是一个windows批处理文件）：
要运行此操作，请创建一个空目录，并将代码块中的文本保存到.cmd文件中。打开一个命令窗口，导航到该文件并执行.cmd
您将在日志文本上方看到以下内容：
添加了1个变更集，其中1个变更为1 文件（+1个磁头）（运行“hg磁头”以请参见标题“hg合并”以合并）
日志文本显示，这两份回购协议确实是合并在一起的在我的理想解决方案中，这会导致错误或请求--force标志

更新（2009年9月10日）：
hg convert
无法满足我的需要。
克隆存储库，然后从新克隆中删除原始远程repo路径（这样就不可能将更改推回到旧的repo）您应该有一个新的完全独立的存储库。
再次使用hg convert及其filemap选项来过滤您的文件

diverge>hg init repo diverge>cd repo diverge\repo>echo some text > file1.txt diverge\repo>hg ci -A -m "added first file" adding file1.txt diverge\repo>echo more text > file2.txt diverge\repo>echo 123 >> file1.txt diverge\repo>hg ci -A -m "some changes and new file" adding file2.txt diverge\repo>hg log 1[tip] 0f37e61d075b 2009-09-11 10:35 +0200 wierob83 some changes and new file 0 b04d9d12fb1d 2009-09-11 10:34 +0200 wierob83 added first file diverge\repo>cd .. diverge>echo include file1.txt > files-in-repo-one.txt diverge>echo exclude file1.txt > files-in-repo-two.txt diverge>hg convert --filemap files-in-repo-one.txt repo new-repo-one initializing destination new-repo-one repository scanning source... sorting... converting... 1 added first file 0 some changes and new file diverge>hg convert --filemap files-in-repo-two.txt repo new-repo-two initializing destination new-repo-two repository scanning source... sorting... converting... 1 added first file 0 some changes and new file diverge>cd new-repo-two diverge\new-repo-two>hg out ..\repo comparing with ..\repo searching for changes abort: repository is unrelated diverge\new-repo-two>hg push ..\repo pushing to ..\repo searching for changes abort: repository is unrelated <-- can't push because its an independent repo
第二次回购似乎仍然相关（我以前不知道；）
我不确定这是预期行为还是bug
更新：

如果创建的一个sup存储库仍然相关，则可以从原始存储库中提取。当拆分过程没有在分支的开头拆分Changset时，会发生这种情况，因为这些Changset不包含应以不同子repo结尾的文件。因此，无需创建新的变更集。
回答您的问题中有关相关存储库的部分。：如果两个Mercurial存储库共享一个公共根，则它们是相关的
更准确地说，如果两个存储库A和B共享一个或多个变更集，则它们是相关的。假设A和B共享一个变更集X。所谓“变更集X”，我指的是具有散列X的变更集——散列值是变更集的标识。哈希值是根据父变更集、日期、提交者和变更本身的哈希值递归计算的。这意味着A和B必须共享X的父变更集。继续这样，我们看到A和B必须共享一个公共根变更集，这是变更集X的祖先
这给了我们一个关于关联的共同定义：它们必须共享一个共同的根。您通常只有一个根变更集，您可以这样看待它：

hg log --rev 0
对于您的情况，我猜convert在两个转换中创建了相同的根变更集。您应该在两个克隆中检查
hg log
，以验证它们是否确实相关。这也应该告诉你为什么他们是相关的

如果您的文件映射在这两个转换中确实包含不同的子树，那么我看不出存储库之间是如何关联的。因此，可能您的include/exclude规则中存在重叠，因此第一个变更集在两次转换中是相等的？
分散存储库是很容易的；只要你觉得合适就克隆/推/拉。Mercurial将把分散的存储库视为相关的。在标准mercurial中，没有任何方法可以阻止从相关存储库中拉取成功；“hg pull”假设你知道自己在做什么
如果从不同的存储库中提取了大量不需要的变更集，您可以通过以下方式清除不需要的变更集：

重命名存储库

使用-r将重命名的存储库克隆回原始名称
选择您想要的头部

（可选）将混乱存储库中的头推到适当的分散存储库，这样您就不会丢失什么都行

删除重命名的存储库

根据您的环境，您可能可以通过人员、文件权限和/或web服务设置一些内容，以保证您所需的内容。
虽然我的问题可能有不同的解决方案，但我最终编写了一个脚本，创建了一个新的回购协议，并将内容引入其中

由于该脚本是Mercurial的外部脚本，Mercurial分配了新的变更集ID（这最终给了我一个新的根），并从本质上分散了repo。我的脚本做了hgconvert所做的事情（我想），但它的方式使生成的存储库被认为是不同的。如果我重新合并了它们（为了论证），它们就不会代表它们的来源。在我对这个假设的重新合并执行
merge
命令之前，每个变更集都会并行运行
如果你真的想
diverge\new-repo-two>cd ..\new-repo-one diverge\new-repo-one>hg out ..\repo comparing with ..\repo searching for changes 1[tip] 62119640bde6 2009-09-11 10:35 +0200 wierob83 some changes and new file

hg log --rev 0