Mercurial 如何合并具有共同祖先但不是同一存储库的克隆的 2 个存储库
我正在使用 hg-subversion,并且我有 2 个不同的 hg 存储库,一个来自我们的 svn 主干,另一个来自主干的分支。我想以某种方式将它们联系起来。在历史上的某个时刻,两个 Hg 存储库将是相同的,是否有某种方法可以加入它们?
换句话说,有没有办法从 Hg 内部关联存储库?
我当前使用的技术是在它们共享的修订的工作副本之上导出第二个存储库,然后将该工作副本作为 Hg 中的分支提交,但这样我会丢失历史记录。
任何建议都会很棒
I am using hg-subversion, and I have 2 different hg repositories one from our svn trunk, and one from a branch of the trunk. I would like to link them somehow. At some point in the history both Hg repositories will be identical is there some way to join them?
In other words is there a way to relate the repositories from within Hg?
The technique I am currently using is to just export the second repository over top of the working copy of the revision they share, and then commit that working copy as a branch in Hg, but I lose the history this way.
Any advice would be great
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以尝试将两个存储库导入到一个存储库中,就像不相关一样,然后将它们合并。 (当你说它们共享一个共同的祖先时,你的意思是这些祖先具有相同的修订 ID 吗?如果是这样,那么这很有可能会很好地工作。)
You could try importing the two repos into one as if unrelated, then merging them. (When you say they share a common ancestor, do you mean that those ancestors have the same revision ID? If so there is a good chance that this will work well.)
您能否重新克隆 Subversion 存储库,将 Subversion 存储库的根作为参数而不是主干或分支之一?我使用过 hg clone svn+ssh://foo/bar/baz 一次,其中 svn+ssh://foo/bar/baz/trunk 是主干,< code>svn+ssh://foo/bar/baz/branches/quux 是一个分支,最后我在 Mercurial 中有两个命名分支,代表 Subversion 主干的“默认”分支和代表 Subversion 主干的“quux”分支分支代表同名的 Subversion 分支。
如果您现有的 hg 存储库中有传出的变更集,那么您可能会遇到一些麻烦。如果只有几个传出变更集,则启用 mq 扩展并将变更集转换为补丁可能会起作用。然后可以将这些补丁重新应用到新克隆(在适当的命名分支中)并最终推送到 Subversion。
Can you re-clone the Subversion repository, giving the root of the Subversion repository as argument instead of trunk or one of the branches? I used
hg clone svn+ssh://foo/bar/baz
once, wheresvn+ssh://foo/bar/baz/trunk
was the trunk andsvn+ssh://foo/bar/baz/branches/quux
was a branch, and in the end I had two named branches in Mercurial, the "default" branch representing Subversion trunk and the "quux" branch representing the like-named Subversion branch.If you have outgoing changesets in your existing hg repos, you might be in a bit of a bind there. If there are just a few outgoing changesets, it might work to enable the
mq
extension and to convert the changesets into patches. These patches can then be re-applied on the new clone (in the appropriate named branch) and eventually pushed to Subversion.