Always fail to apply SVN patch on remote Linux machine

Question

My typical work process is like:

1. Check out the codes from trunk on to my windows work machine
2. Do some fixes (but no commit the SVN) and create a patch of these modifications using Tortoise SVN's "Create Patch".
3. SSH log into a remote Linux server, and upload the patch. The linux server also has the trunk HEAD checked out.
4. Apply the patch on the Linux Server like:

[work@remoteLinuxBox:~/work] patch -p0 -i ~/work/fix.patch
(Stripping trailing CRs from patch.)
patching file src/java/main/myApp/view/action/test/launch/GetPeekAction.java
Hunk #1 FAILED at 385.
1 out of 1 hunk FAILED -- saving rejects to file src/java/main/myApp/view/action/test/launch/GetPeekAction.java.rej
(Stripping trailing CRs from patch.)
patching file src/java/main/myApp/view/action/test/GetAllCustomerAction.java
Hunk #1 FAILED at 76.
1 out of 1 hunk FAILED -- saving rejects to file src/java/main/myApp/view/action/test/GetAllCustomerAction.java.rej
(Stripping trailing CRs from patch.)

But I always got errors like these. I thought it was caused by the reason that the end of the line is different on windows and Linux, so I converted the patch using dos2unix, the warning like (Stripping trailing CRs from patch) disappeared, but the patching still failed.

There is one strange behavior that if the modification for a file only happens on a existing line, applying patch will work. But if there are new lines added, the patch gets failed.

Anyone has clue on how to resolve this? Thanks very much

Answer 1

Use cygwin svn diff to avoid the headache, will make sure that the header of each hunk has only LF as a line ending instead of CR+LF. The Linux patch command does not play well with hunk headers having CR+LF line endings. To me TortoiseSVN/create patch is broken because the patches it creates are not cross-platform.

Answer 2

I had a similar problem, and I figured that not only the line delimiters of the patch-file are important, but of your working copy as well.

My working copy had Windows Line Endings (CR+LF), but after I converted the affected files (in the working copy) to Unix Line Endings, the patch worked! The problem is, that now my file comparison tool shows that the working copy files are different from the repository in every single line - because of different line endings. I think, I will end up converting the whole repository to Unix line endings, if Windows can deal with them.

Hope it helps.