[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn diff behaviour with eol-style=native?

From: Louis-Philippe Gagnon <louisphilippe_at_macadamian.com>
Date: 2006-09-04 19:33:47 CEST

I've encountered an odd behaviour when using "svn diff" on a file marked
with sv:eol-style=native, when working in Windows.

Note that this isn't a "help, what do I do?" message, nor a "this
program is broken!" message; more of a "how odd; anyone know something
about this?" message. Please take it in that spirit ;)

(tested with official Windows build of svn 1.3.2)

Briefly: svn diff on a eol-style=native file generates an output with
mixed-mode line endings; "control lines" ("Index: filename" and such)
use native, CRLF line endings, but actual context and modified lines use
Unix-style (LF-only) line endings.

This has the unfortunate consequence that on Windows, with an
eol-style=native file, even a simple "svn diff | patch -R" fails, as the
diff's line endings don't match those of the working copy.
(actually, as can be seen in the transcript below, patch.exe crashes.
But that's a problem with the port of patch.exe I'm using, obviously not
svn's fault)

There are reasonably simple workaround; filtering the diff through
unix2dos "fixes" things so that all lines end in CRLF; telling sv to use
an external diff tool also works.

(one experiment I'm not currently set up to try is whether the
mixed-mode diff would apply cleanly on a Unix system)

I can't imagine I'm the first to notice, but I haven't been able to find
any previous discussion on the subject on the subversion mailing lists.

I did find some somewhat-related info:

very old subversion issues: 851, 894

-> sounds like svn diff used to compare working copy & text-base without
any conversion; note that the solution suggested in this message ("the
text base has to be converted to native format") seems to be the exact
opposite of the current behaviour.

-> post "Subversion DIFF EOL Caveats" sounds like what i've observed;
the suggestion to use an external diff did indeed work for me.

So... bug? feature?

Here's a short scenario illustrating how to reproduce the issue:


D:\src\svn\checkedout>echo line1 > file.dos

D:\src\svn\checkedout>svn add file.dos
A file.dos

D:\src\svn\checkedout>svn propset svn:eol-style native file.dos
property 'svn:eol-style' set on 'file.dos'

D:\src\svn\checkedout>svn ci file.dos
Adding file.dos
Transmitting file data .
Committed revision 2.

D:\src\svn\checkedout>echo line2 >> file.dos

D:\src\svn\checkedout>svn diff file.dos > file.diff

D:\src\svn\checkedout>svn revert file.dos
Reverted 'file.dos'

D:\src\svn\checkedout>patch -p0 < file.diff
patching file file.dos
Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 339

abnormal program termination

D:\src\svn\checkedout>svn --version
svn, version 1.3.2 (r19776)


I learned years ago to recognize this crash as being caused by feeding a
file with Unix line endings to patch.exe. This was the first time I'd
ever fed it a mixed-mode diff, though :)
(I was slightly surprised to see the UnxUtils and GnuWin32 ports of
patch BOTH had the same problem, despite being several years apart)

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 6 22:45:27 2006

This is an archived mail posted to the Subversion Users mailing list.