View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000093||Subversion for OS/2 & eCS||public||2006-10-01 02:26||2007-03-09 17:20|
|Target Version||Fixed in Version|
|Summary||0000093: Output of 'svn diff' on LF-only files lacks CR|
|Description||Check out a file in UNIX format.|
Run 'svn diff'
Output is hard to read because newlines don't contain CR:
--- unixfile.txt (revision 2)
+++ unixfile.txt (working copy)
@@ -1,4 +1,4 @@
This is a test file for Subversion
-This line contains the text to be modified.
+This line contains the text which is modified.
\ No newline at end of file
|Additional Information||I did not see this problem in the previous version.|
|Tags||No tags attached.|
||Just a note to say this issue still exists in 1.4.3.|
diff_sample.zip (2,294 bytes)
I've done some analysis of this issue. Best I can tell the subversion code is OK. It uses APR_EOL to ensure that the correct EOL markers are used. This means that the diff headers have the correct EOL markers. The source code lines are what have incorrect EOL markers. This is probably because these lines are output by lower level stream output functions in the APR runtime that do not honore APR_EOL.
I'll add some more to this note when I track down the code that is actually ouputting the unified diff source lines.
At bit more hunting makes me suspect that svn_subst_translation_required() in
subversion\libsvn_subr\subst.c might be a possible culprit. The working copies have CR/NL EOLs while the text_base copies have unix style NL EOLs.
It's also possible that the translation happens for the diff phase, but is neglected for the output phase. This would occur if the file images used for the diff phase is discarded after it is tokenized. If so, the would need to be retrieved again when to differences are output.