【问题标题】:Always fail to apply SVN patch on remote Linux machine总是无法在远程 Linux 机器上应用 SVN 补丁
【发布时间】:2011-04-14 01:51:40
【问题描述】:

我的典型工作流程是这样的:

  1. 在我的 Windows 工作机器上查看中继中的代码
  2. 做一些修复(但不提交 SVN)并使用 Tortoise SVN 的“创建补丁”创建这些修改的补丁。
  3. SSH 登录到远程 Linux 服务器,并上传补丁。 linux 服务器还检查了主干 HEAD。
  4. 在 Linux 服务器上应用补丁,例如:
[work@remoteLinuxBox:~/work] 补丁 -p0 -i ~/work/fix.patch (从补丁中剥离尾随 CR。) 修补文件 src/java/main/myApp/view/action/test/launch/GetPeekAction.java Hunk #1 在 385 失败。 1 / 1 大块失败 - 将拒绝保存到文件 src/java/main/myApp/view/action/test/launch/GetPeekAction.java.rej (从补丁中剥离尾随 CR。) 修补文件 src/java/main/myApp/view/action/test/GetAllCustomerAction.java Hunk #1 在 76 时失败。 1 个大块中的 1 个失败 - 将拒绝保存到文件 src/java/main/myApp/view/action/test/GetAllCustomerAction.java.rej (从补丁中剥离尾随 CR。)

但我总是遇到这样的错误。我以为是windows和linux下行尾不同的原因,所以我用dos2unix转换了patch,(Stripping trailing CRs from patch)之类的警告消失了,但是还是打补丁失败了。

有一种奇怪的行为,如果对文件的修改仅发生在现有行上,则应用补丁将起作用。但是如果添加了新行,补丁就会失败。

有人知道如何解决这个问题吗?非常感谢

【问题讨论】:

标签: linux svn patch


【解决方案1】:

使用 cygwin svn diff 来避免头痛,将确保每个大块的标题只有 LF 作为行尾而不是 CR+LF。 Linux 补丁命令不能很好地处理具有 CR+LF 行结尾的块头。 对我来说 TortoiseSVN/create 补丁被破坏了,因为它创建的补丁不是跨平台的。

【讨论】:

    【解决方案2】:

    我遇到了类似的问题,我认为不仅补丁文件的行分隔符很重要,你的工作副本也很重要。

    我的工作副本有 Windows 行尾 (CR+LF),但在我将受影响的文件(在工作副本中)转换为 Unix 行尾后,补丁就起作用了!问题是,现在我的文件比较工具显示工作副本文件在每一行中都与存储库不同——因为行尾不同。我想,如果 Windows 可以处理它们,我最终会将整个存储库转换为 Unix 行尾。

    希望对你有帮助。

    【讨论】:

      【解决方案3】:

      您可以尝试在修补命令中添加“-l --binary”,如下所示:

          patch -p0 -l --binary < patch.diff
      

      【讨论】:

      • 太晚了!由于创建时工作副本中文件的行结尾错误,补丁被搞砸了。你不能这样拧下来。
      猜你喜欢
      • 1970-01-01
      • 2015-07-22
      • 1970-01-01
      • 1970-01-01
      • 2012-05-07
      • 2014-11-02
      • 1970-01-01
      • 2012-07-16
      • 1970-01-01
      相关资源
      最近更新 更多