我已经开始在SVN存储库中工作了。我已经将其子文件夹克隆到了hg clone的本地Hg仓库中。
之后，我想与一位无权访问SVN存储库的同事分享。我已经创建了一个私有BitBucket存储库，我们偶尔会推动这些更改，因此我不得不将它们拉出来。
hgsubversion为变更集做了一些讨厌的事情，比如改变他们的提交者（我甚至相信哈希）。当我尝试推送到BitBucket仓库时，我不得不进行合并。
现在由于我们心爱的朋友abort: Sorry, can't find svn parent of a merge revision.，我无法将更改推回到Subversion存储库中。
如何使用svn-targetinging Mercurial存储库拉出BitBucket目标Mercurial存储库，同时保持与hgsubversion兼容（即不导入合并修订版）？
当然，一些自动化的方法会受到赞赏，但如果没有这样的事情/简单方法，我会感激任何解决方案。
我使用的是hgsubversion，而不是hgsvn;也就是说，hg clone svn://repo/url的延伸。不过，如果有必要，我愿意转换。
答案 0 :(得分：21)
当你在subversion存储库上使用Mercurial时，你仍然必须像SVN一样思考，因此基本的mercurial工作流的很多功能部分都无法工作。合并mercurial的方式在svn仓库中是不可能的。如果你已经将你的工作与拉动的svn分支合并，你将会得到你现在得到的臭名昭着的消息:(
我建议你阅读durin42对this question的回答。
编辑：为了摆脱目前的混乱局面，我建议你从SVN仓库结账时创建一个补丁（或一系列补丁）。从subversion存储库获取新的新副本并应用补丁。我不确定你是否可以从你目前的回购中做到这一点。你可以探索hg diff命令。
hg diff -g -r tip -r XXX > patch
XXX是你原来的SVN结账（我还没有测试过。）
答案 1 :(得分：10)
是的，hgsubversion确实更改了提交者名称，因为它必须反映Subversion指定的名称。 Hgsubversion 必须然后还会更改变更集散列。它并不是hgsubversion可以决定的东西 - 它在Mercurial的设计中内置，变更集散列基于变更集中的所有信息，包括提交者的名称。
请阅读我的hgsubversion guide，了解有关如何正确使用hgsubversion的信息。要记住的重点是hgsubversion将hg转换为更好的svn，但它仍然是Subversion，它是主人。这意味着您必须先将历史记录线性化，然后再将其推回到Subversion，这样就不会出现合并或其他有趣的DVCS事件。
如果你想利用Mercurial中的分布式功能，那么可以在小的迭代中进行：在Mercurial中进行一些协作，线性化变更集并推回Subversion，破坏克隆的非线性部分，拉来自Subversion。然后，您可以在Mercurial中重复使用新的协作迭代。
答案 2 :(得分：0)
我刚遇到类似问题，基本上是：
并遇到了可怕的Sorry, can't find svn parent of a merge revision消息。
这就是我在没有太多麻烦的情况下解决它的问题：
SVN Checkout...命令将SVN repo签出到新文件夹（右键单击以访问它）。.hg子文件夹除外）复制到新创建的SVN文件夹中，覆盖所有文件。SVN Commit...。需要2分钟，一切都应该重新开始了。你会失去一些合并和提交信息，但它不应该是一个问题，因为SVN / HgSubversion组合无论如何都无法跟踪它们。