在Mercurial储存库时间轴中拼接不连续性 [英] Splicing over discontinuities in Mercurial repository timeline

查看:67
本文介绍了在Mercurial储存库时间轴中拼接不连续性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

几个月前,我将Subversion存储库转换为Mercurial,最后我在修订历史中留下了两个毫无意义的空白.我正在尝试找出是否可以弥补差距,但是我还没有能够获得能够精确完成我想要的工具的工具.

在项目初期,我已经对Subversion仓库进行了两次重组:首先将单个项目的根目录转换为主干/分支/标签布局,然后在第二个相关项目中使用其自己的主干添加第二个相关项目/分支机构/标签.

当我决定改用Mercurial时,在第一个原始项目的主干之外没有任何重要的开发活动.我想能够使用Mercurial转换实用程序和路径映射在新的Mercurial存储库中重新组合一个明智的主干.

现在我意识到我有两个额外的头,每个头都对应于更改历史记录从头开始的地方:

r0 ... r16 | (r17) r18 ... r61 | (r62) r63 ... tip

中断后的两个修订的结果r17和r62与中断前的相应修订的内容相同-它们完全由文件添加操作组成,其内容与先前的修订完全相同.有意义的更改仅从下一个修订版开始(分别为r18和r63).

我搞砸了Mercurial Transplant扩展程序,以尝试在r17和r62上进行拼接,但最终将拼接的变更集连接到默认分支的尖端(此时为r405).

这些多余的头脑并没有真正损害我的开发活动,因此我已经放了一段时间.促使我解决此问题的原因是,每次我从远程存储库中提取时,MercurialEclipse都会抱怨这些额外的问题.

任何人都可以提供有关如何解决此问题的建议吗?我只是在错误地获得命令标志,还是我使用了错误的工具?我应该改用Rebase扩展程序吗?我们都曾经使用过Subversion的某种转储编辑转储文件重新加载过程怎么样?

虽然我已将项目发布到开发服务器,但那里只有几个克隆,因此销毁这些副本并重新克隆应该没什么大不了的.

解决方案

扩展命令 rebase collapse 应该可以解决问题.以以下小型存储库为例:

$ hg glog -p

o  changeset:   3:bc701d12d956
|  tag:         tip
|  summary:     hack
|
|  diff --git a/file b/file
|  --- a/file
|  +++ b/file
|  @@ -1,1 +1,1 @@
|  -hello world
|  +hello big world
|
o  changeset:   2:2bb8c95d978e
   parent:      -1:000000000000
   summary:     history breaking svn reorganization

   diff --git a/file b/file
   new file mode 100644
   --- /dev/null
   +++ b/file
   @@ -0,0 +1,1 @@
   +hello world

@  changeset:   1:b578b2ec776b
|  summary:     hack
|
|  diff --git a/file b/file
|  --- a/file
|  +++ b/file
|  @@ -1,1 +1,1 @@
|  -hello
|  +hello world
|
o  changeset:   0:c3d20f0b7072
   summary:     initial

   diff --git a/file b/file
   new file mode 100644
   --- /dev/null
   +++ b/file
   @@ -0,0 +1,1 @@
   +hello

这基本上与您的情况类似,即有两个不相关的历史记录行,其中第二行(r2)的第一个修订版是第一行(r1)的最后一个修订版中所有内容的简单补充.

您可以使用 rebase 将第二行放在第一行:

$ hg rebase -s 2 -d 1
$ hg glog

@  changeset:   3:020d1b20caa8
|  summary:     hack
|
o  changeset:   2:2a44eb4b74c3
|  summary:     history breaking svn reorganization (empty changeset now)
|
o  changeset:   1:b578b2ec776b
|  summary:     hack
|
o  changeset:   0:c3d20f0b7072
   summary:     initial

如您所见,这两行已合并.修订版2现在是一个过时的空白变更集.您可以使用 collapse 命令合并修订版1和2来摆脱它:

$ hg collapse -r 1:2
<edit commit message>
$ hg glog -p

@  changeset:   2:d283fe96a5e6
|  tag:         tip
|  summary:     hack
|
|  diff --git a/file b/file
|  --- a/file
|  +++ b/file
|  @@ -1,1 +1,1 @@
|  -hello world
|  +hello big world
|
o  changeset:   1:c486d8191bf0
|  summary:     hack
|
|  diff --git a/file b/file
|  --- a/file
|  +++ b/file
|  @@ -1,1 +1,1 @@
|  -hello
|  +hello world
|
o  changeset:   0:c3d20f0b7072
   summary:     initial

   diff --git a/file b/file
   new file mode 100644
   --- /dev/null
   +++ b/file
   @@ -0,0 +1,1 @@
   +hello

现在,不相关的历史线以有意义的方式结合在一起.

I converted a Subversion repository to Mercurial a few months back and I wound up leaving two meaningless gaps in my revision history. I'm trying to figure out if I can just splice over the gaps, but I haven't been able to get the tools to do precisely what I want.

I had reorganized the Subversion repo twice in the early days of the project: first to convert a single project root to trunk/branches/tags layout, and then to add a second related project in a second root folder with it's own trunk/branches/tags.

By the time I decided to switch to Mercurial there had been no significant development activity outside of the trunk of the first, original project. I was able to use the Mercurial conversion utilities and path mapping to reassemble a single sensible trunk in the new Mercurial repository, or so I thought.

Now I realize that I have two extra heads, each corresponding to where the change history essentially starts over:

r0 ... r16 | (r17) r18 ... r61 | (r62) r63 ... tip

The results of the two revisions after the breaks, r17 and r62, are identical in content to the corresponding revision before the breaks -- they consist entirely of file add operations with exactly the same contents as the previous revisions. Meaningful changes only start at the next revisions (r18 and r63 respectively).

I've messed with the Mercurial Transplant extension in an attempt to splice over r17 and r62, but it winds up concatenating the spliced changesets all the way at the tip of the default branch (r405 at this point).

These extra heads are not really hurting my development activities, so I've let it go for a while. What's pushing me to resolve this is that MercurialEclipse complains about these extra heads every time I pull from my remote repository.

Can anyone offer any advice on how to approach this? Am I just getting the command flags wrong, or am I using the wrong tool? Should I be using the Rebase extension instead? What about some sort of dump-edit dumpfile-reload process that we all used to do with Subversion?

While I've published the project to my development server, there are only a couple of clones out there, so destroying those copies and recloning shouldn't be a big deal.

解决方案

The extension commands rebase and collapse should do the trick. Consider the following small repository as an example:

$ hg glog -p

o  changeset:   3:bc701d12d956
|  tag:         tip
|  summary:     hack
|
|  diff --git a/file b/file
|  --- a/file
|  +++ b/file
|  @@ -1,1 +1,1 @@
|  -hello world
|  +hello big world
|
o  changeset:   2:2bb8c95d978e
   parent:      -1:000000000000
   summary:     history breaking svn reorganization

   diff --git a/file b/file
   new file mode 100644
   --- /dev/null
   +++ b/file
   @@ -0,0 +1,1 @@
   +hello world

@  changeset:   1:b578b2ec776b
|  summary:     hack
|
|  diff --git a/file b/file
|  --- a/file
|  +++ b/file
|  @@ -1,1 +1,1 @@
|  -hello
|  +hello world
|
o  changeset:   0:c3d20f0b7072
   summary:     initial

   diff --git a/file b/file
   new file mode 100644
   --- /dev/null
   +++ b/file
   @@ -0,0 +1,1 @@
   +hello

It basically resembles your situation, i.e. there are two unrelated lines of history, where the first revision of the second line (r2) is a plain add of everything present at the last revision of the first line (r1).

You can put the second line onto the first one with rebase:

$ hg rebase -s 2 -d 1
$ hg glog

@  changeset:   3:020d1b20caa8
|  summary:     hack
|
o  changeset:   2:2a44eb4b74c3
|  summary:     history breaking svn reorganization (empty changeset now)
|
o  changeset:   1:b578b2ec776b
|  summary:     hack
|
o  changeset:   0:c3d20f0b7072
   summary:     initial

As you see, the two lines have been joined. Revision 2 now is an obsolete empty changeset. You can get rid of it by using the collapse command to combine revisions 1 and 2:

$ hg collapse -r 1:2
<edit commit message>
$ hg glog -p

@  changeset:   2:d283fe96a5e6
|  tag:         tip
|  summary:     hack
|
|  diff --git a/file b/file
|  --- a/file
|  +++ b/file
|  @@ -1,1 +1,1 @@
|  -hello world
|  +hello big world
|
o  changeset:   1:c486d8191bf0
|  summary:     hack
|
|  diff --git a/file b/file
|  --- a/file
|  +++ b/file
|  @@ -1,1 +1,1 @@
|  -hello
|  +hello world
|
o  changeset:   0:c3d20f0b7072
   summary:     initial

   diff --git a/file b/file
   new file mode 100644
   --- /dev/null
   +++ b/file
   @@ -0,0 +1,1 @@
   +hello

Now the unrelated lines of history are joined in a meaningful way.

这篇关于在Mercurial储存库时间轴中拼接不连续性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆