version-control - Mercurial 导入补丁失败时怎么办？

Question

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

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 服务器存储库的写访问权限。因此，为了获得我的变更集，我必须将其导出为补丁并将其提交给维护人员。

Answer 1

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

换句话说，听起来您有以下情况:

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

如果我知道补丁最初基于的变更集，我会做什么，将更新回该变更集，应用补丁，这将添加另一个头，然后将其合并到您的存储库的提示中。

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

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

现在，换一种方式。

使用补丁是唯一的方法吗？使用 Mercurial 时的一种常见方法是设置自己的存储库，一个分支，最初包含中央存储库的完整克隆，但您具有提交访问权限。

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

如果中央存储库在您克隆后添加了新的变更集，在某个时候您从它拉入您的克隆，然后合并。

然后当你满意时，你向中央存储库的维护者发出拉取请求，告诉他们“嘿，我有一些更改给你，你可以从这里从我的克隆中拉取它们: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
               |            |
               +------------+

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

有关 fork 的更多信息，请查看 Tekpub 关于 CodePlex 和 Mercurial 的视频，此处: Tekpub: 7 - Mercurial With CodePlex , 寻找到 21:15 左右开始 fork 部分。

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