当Mercurial导入的补丁失败时该怎么办?

时间:2011-01-04 08:56:38

标签: version-control mercurial tortoisehg

从服务器存储库中取出后,我从本地工作仓库导出了一堆变更集。为了确保补丁工作,我从服务器克隆了一个新的repo,我尝试应用变更集。不幸的是,导入失败了:

applying G:\OSS\premake-dev\premake-dev_rev493.patch
unable to find 'src/host/scripts.c' for patching
3 out of 3 hunks FAILED -- saving rejects to file src/host/scripts.c.rej
patching file src/base/api.lua
patching file src/host/scripts.c
patching file src/tools/bcc.lua
file tests/test_bcc.lua already exists
1 out of 1 hunks FAILED -- saving rejects to file tests/test_bcc.lua.rej
patching file tests/premake4.lua
patching file tests/test_bcc.lua
abort: patch failed to apply

[command interrupted]

我知道失败的原因,这是由于最新变更集中不再存在已删除的源文件。但我不确定如何修复我的补丁,以便它可以干净地应用于当前的服务器存储库。

我对Mercurial相当陌生,所以使用的一些术语我并不熟悉。另请注意,我没有对Hg服务器存储库的写访问权限。因此,为了获得我的变更集,我必须将其作为补丁导出并将其提交给维护者。

2 个答案:

答案 0 :(得分:13)

我必须承认没有经常使用补丁,所以这可能不是正确的工作流程,但我会尝试,如果我在那种情况下将补丁应用于它最初基于的变更集。 / p>

换句话说,听起来你有以下几种情况:

                    +-- you're here
                    |
                    v
1---2---3---4---5---6
     \
      \
       X <-- patch was built to change 2 to X

如果我知道补丁最初所基于的变更集,我会做什么,将更新回更改集,应用补丁,这将添加另一个头,然后将其合并到存储库的提示。< / p>

执行这些操作后,存储库应如下所示:

                        +-- you're here
                        |
                        v
1---2---3---4---5---6---8
     \                 /
      \               /
       7-------------/
       ^
       |
       +-- this is the changeset you committed after applying the patch

现在,以不同的方式。

是否只使用补丁?使用Mercurial时,一种常见的方法是设置自己的存储库,一个fork,最初包含中央存储库的完整克隆,但您具有提交权限。

因此,您可以将新的变更集提交到自己的克隆中。

如果中央存储库在您克隆后添加了新的更改集,则在某些时候将其从克隆中拉出并合并。

然后,当您满意时,向中央存储库的维护者发出拉取请求,告诉他们“嘿,我有一些更改,您可以从我的克隆中提取它们:http://。 ..“。

通过这种方式,这些维护人员可以轻松搞定所有内容,因为您已经为他们完成了所有艰苦的工作。

这意味着你有两个这样的存储库:

central: 1--2

clone:   1--2

你添加你的作品:

central: 1--2

clone:   1--2--3

他们添加了一些变更集:

central: 1--2--3--4--5--6

clone:   1--2--3

然后你拉:

central: 1--2--3--4--5--6

clone:   1--2--4--5--6--7
             \
              \
               3  <-- this is your changeset

然后你合并:

central: 1--2--3--4--5--6

clone:   1--2--4--5--6--7--8
             \            /
              \          /
               3--------/

如果维护人员现在从您那里取消,他们会在他们的存储库中获得完全相同的历史记录。

还有一些对rebase的支持,这意味着你不需要拉动和合并,但维护者会发出“pull with rebase”命令,实际上将你的变更集从当前位置重新定位到新位置在他们的存储库中,这将是这样的:

central: 1--2--3--4--5--6---7
                            ^
clone:   1--2--3            |  relocated here
               |            |
               +------------+

这只有在没有合并冲突的情况下才有效。拉动和合并的方法对他们来说是最好的,因为你做了所有艰苦的工作,他们只需要验证代码是他们想要的。

有关分叉的更多信息,请查看Tekpub在CodePlex和Mercurial上的视频,在这里:Tekpub: 7 - Mercurial With CodePlex,寻求到21:15左右开始分叉。

请注意,“fork”基本上只是一个克隆,在CodePlex中分叉的方式是它自动在您自己的帐户上设置克隆,并向原始维护者发送拉取请求,但是如果您创建自己的帐户在Bitbucket或CodePlex或其他任何地方,在那里发布您的克隆,只需向维护者发送一封包含您的存储库URL的电子邮件,这就是它的全部内容。

答案 1 :(得分:2)

在我的情况下,我失败的 hg import 与行结尾有关。解决方案是将其放在我的〜/ .hgrc 文件中:

Action<bool, double>