本文介绍了在Mercurial中作父母:如何将两个独立的svn克隆带回到一起?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在这种情况下:开发人员Foo从我们的svn存储库创建了一个hg存储库. Foo的汞回购协议只是svn中树干的浅表克隆(没有svn分支,标签等,并且历史记录不完整[大约100个变更集]). Developer Bar做了同样的事情,但是克隆了整个svn存储库,包括整个历史记录,分支,标签等.Foo和Bar都在其存储库上进行了分支开发.

Here's the situation: developer Foo created a hg repo from our svn repo. Foo's hg repo was only a shallow clone of the trunk in svn (no svn branches, tags, etc. and the history was incomplete [about 100 changesets]). Developer Bar did the same thing, but cloned the entire svn repo including the entire history, branches, tags, etc. Both Foo and Bar have done branchy development on their repositories.

两个存储库都有一个通用的SVN祖先,但是每个hg存储库都有一个不同的版本号.我想拒绝Foo从共同祖先到Bar的仓库的变化.这是我正在寻找的图表:

There is a common SVN ancestor to both repositories, but each hg repo has a different version number for it. I would like to reparent Foo's changes from the common ancestor onto Bar's repo. Here's a diagram of what I'm looking for:

Foo的仓库:

C'-D'-E-F---G
       \   /
        H-I

酒吧的仓库:

...A-B-C-D-J-K---L
            \   /
             M-N

C,C'和D,D'具有相同的内容,但版本号&评论.

C,C' and D,D' have the same content, but different version numbers & comments.

目标:

...A-B-C-D--E-F---G
          \  \   /
           \  H-I
            \
             J-K---L
              \   /
               M-N

关于如何实现这一目标的想法我已经用光了.我尝试了转换--splicemap splice.map [包含E D的splice.map文件](什么也没做).克隆-f设法将所有内容放入一个存储库中,但是它们似乎是独立的树.在克隆-f之后,我尝试重新设置--source E --dest D --detach,但是它只是崩溃了:(

I've run out of ideas on how to make this happen. I tried convert --splicemap splice.map [splice.map file contained E D] (didn't do anything). Clone -f managed to get everything into one repo, but they appear to be independent trees. After clone -f, I tried rebase --source E --dest D --detach, but it just crashed :(

想法?

我知道更改历史记录会使任何人的存储库克隆失效,在这种情况下这不是问题.所有用户将从此努力的结果中重新克隆.

I'm aware altering the history will invalidate anyone's clone of the repositories, this is not a problem in this case. All users will be re-cloning from the result of this effort.

推荐答案

已解决!

SOLVED!

最初我没有注意到的一件事是我的假定共同祖先毕竟并不完全相同.在Foo的回购的svn-> hg转换过程中,$ ID $字符串得到了扩展,但没有在Bar的回购中创建.下面的步骤1是创建REAL共同祖先的简单修补程序.

One thing I didn't notice initially was that my presumed common ancestor wasn't exactly the same after all. During the svn->hg conversion of Foo's repo, the $ID$ strings were expanded, but were not in the creation of Bar's repo. Step 1 below was a simple fix to create a REAL common ancestor.

以下步骤使我得以实现自己的目标:

The following steps allowed me to accomplish my goal:

1-确保假定的共同祖先(D和D')实际上是相同的.如果不是,请在Bar的存储库中为它们创建一个新的拼接点(S).在我的示例中,S应该与D'的内容完全匹配.

1- Ensure that the presumed common ancestor (D and D') are actually identical. If not, create a new splice point for them (S) in Bar's repo. S should exactly match the content of D' in my example.


    ...A-B-C-D--J-K---L
              \  \   /
               S  M-N

2-


    hg convert --splicemap TrimSplicemap Foo FooTrimmed

TrimSplicemap内容:(其中E是E的完整哈希)

TrimSplicemap contents: (where E is the full hash of E)


    E 0000000000000000000000000000000000000000

3-使用hg strip删除断开连接的冗余历史记录

3- Use hg strip to remove the disconnected, redundant history


    cd FooTrimmed
    hg strip C'

4-再次使用hg convert在提交"S"时将Foo的剥离存储库拼接到Bar的存储库中

4- Use hg convert again to splice Foo's stripped repo onto Bar's repo at commit 'S'


    cd ../Bar
    hg convert --splicemap FooBarSplicemap ../FooTrimmed .

FooBarSplicemap的内容:(其中E'是FooTrimmed中E的新哈希,而S是S的哈希)

FooBarSplicemap contents: (where E' is the NEW hash for E in the FooTrimmed, and S is the hash of S)


    E' S

那应该做! :D

这篇关于在Mercurial中作父母:如何将两个独立的svn克隆带回到一起?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

05-29 02:13
查看更多