GNOME Bugzilla – Bug 613685
Invoking 'patch' failed - svn diff for files with "svn:eol-style"
Last modified: 2012-12-02 22:06:25 UTC
Created attachment 156854 [details] svn diff for file that produces the error in Meld I'm not able to see with svn diffs when a file has svn properties set to "native" for "svn:eol-style" in cases where the modified file's EOL differs from the native EOL. Specifically: My platform is Linux, but the files in question are edited in Windows (within a VM on my system). So even though the "native" EOL for the files on my system are "\n", the modified files have "\r\n". The files correctly are shown in Meld's list of modified files, but when I click on one I get the error dialog "Invoking 'patch' failed." I definitely have "patch" installed: $ which patch /usr/bin/patch $ patch -v patch 2.5.9 - meld version: '1.3.1' - source control software type: 'Subversion' - source control software version: 'version 1.6.6 (r40053)' - the output of 'svn diff somefile.txt' (see attachment) - patch command: 'patch --strip=0 --reverse --directory=/home/jkeller/tmp/tmpzHueT7-meld' I've attached a sample file, but this happens for any file with the conditions I described above. Note that "svn diff" hasn't had problems with any of them (but of course Meld's diff is *much* nicer to use). Please let me know if you need any other information, I'd be happy to help out.
The problem is that Meld expects to be able to reverse apply the result of 'svn diff' to the current version to get the original file back. I guess the problem is that the file on the filesystem contains \n, and svn diff gives you a diff with \r\n line endings? Though I'm not confident it will help, could you please retry with Meld from current git (anything after http://git.gnome.org/browse/meld/commit/?id=c4de90ce4d4a39b86599b3af90989dab76866d1f would be fine; that was a patch to deal with another issue of svn diff lying to us).
Created attachment 183581 [details] Another failing diff Still fails. Long story below: > Invoking 'patch' failed. > > Maybe you don't have 'GNU patch' installed, > or you use an untested version of Subversion. > > Please send email bug report to: > meld-list@gnome.org > > Containing the following information: > > - meld version: '1.4.0' > - source control software type: 'Subversion' > - source control software version: 'X.Y.Z' $ svn --version svn, version 1.6.15 (r1038135) > - the output of 'svn diff somefile.txt' svn diff of the file attached (it does have crlf lines) meld was invoked as 'meld SpecialVersion.php' on its folder. It fails every time. > - patch command: 'patch --strip=0 --reverse --directory=/tmp/tmp4WPaZy-meld' > (no need to actually run it, just provide > the command line) > > Replace 'X.Y.Z' by the actual version for the > source control software you use. $ patch --version > patch 2.6.1 > Copyright (C) 1988 Larry Wall > Copyright (C) 2003, 2009 Free Software Foundation, Inc. I then tried building from git (revision 8d219406af89921a92a4ab1df9aa92f9326a3947) Fails with the same error, but now it says <- meld version: '1.5.0'>.
The SVN documentation doesn't indicate that it does anything different for svn diff when eol-style is set. However, I guess what it *actually* does is ignore line-ending differences when generating the diff? I'm not against working around this in Meld, but the current structure of our version-control system makes it hard to keep this clean. We already have a workaround in place to support SVN's external diff command option; I imagine that a similar workaround for eol-style could be developed. As reference for anyone interested in writing a patch, I think we'd want to: * Try to diff/patch normally * If the patch failed, check to see whether the file has eol-style set to 'native' * Re-diff/patch with -x --ignore-eol-style which I *think* should roughly reproduce what SVN expects. As a quick test, you could change diff_command() in meld/vc/svn.py, appending -x --ignore-eol-style and see if that helps matters.
Could you please test the patch I've just attached to bug 557615? I think it should work around the problem by not actually using patch. Note that this won't work for SVN 1.7 though.
The branch from the other SVN fix has been pushed, and to the best of my knowledge, it should fix this too. Since I don't have any feedback to the contrary, I'm just going to close this bug.