On Thu, 30 Jun 2005 kfogel@collab.net wrote:
> > FAIL: diff_tests.py 14: diff text-bases against repository
>
> I have sort-of-kind-of access to a Windows machine, so I looked at how
> 'svn diff' behaves on Windows. Unless I misinterpreted the output,
> the answer ain't pretty. Watch this:
>
> C:\WINDOWS\temp\kff\subversion-trunk\notes>svn --version
> ... 1.2.0 ...
> C:\WINDOWS\temp\kff\subversion-trunk\notes>svn plist -v skip-deltas
> C:\WINDOWS\temp\kff\subversion-trunk\notes>svn plist -v svndiff
> Properties on 'svndiff':
> svn:eol-style : native
> C:\WINDOWS\temp\kff\subversion-trunk\notes>notepad skip-deltas
> [... make trivial edits to a couple of lines, save ...]
> C:\WINDOWS\temp\kff\subversion-trunk\notes> notepad svndiff
> [... make trivial edits to a couple of lines, save ...]
> C:\WINDOWS\temp\kff\subversion-trunk\notes>cd ..
> C:\WINDOWS\temp\kff\subversion-trunk>svn diff notes
> Index: notes/skip-deltas^M
> ===================================================================^M
> --- notes/skip-deltas (revision 15200)^M
> +++ notes/skip-deltas (working copy)^M
> @@ -59,7 +59,7 @@^M
> In the BDB back end, each revision of a file is represented as a delta
> against a newer revision of the file--the opposite of FSFS. The
> newest version of a file is stored in plain text. Whereas in FSFS, we
> -add a new version of a file simply by picking a delta base and writing
> +add a new version of a file simply by xpicking a delta base and writing
> out a delta, in BDB the process is more complicated: we write out the
> new version of the file in plain text; then, after the commit is
> confirmed, we go back and "redeltify" one or more older versions of
> Index: notes/svndiff^M
> ===================================================================^M
> --- notes/svndiff (revision 15200)^M
> +++ notes/svndiff (working copy)^M
> @@ -17,8 +17,8 @@^M
> window.
>
> An svndiff document begins with four bytes, "SVN" followed by a zero
> -byte which represents a version number. After the header come one or
> -more windows, until the document ends. (So the decoder must have
> +byte xwhich represents a version number. After the header come one or
> +more xwindows, until the document ends. (So the decoder must have
> external context indicating when there is no more svndiff data.)
>
> A window is the concatenation of the following:
> C:\WINDOWS\temp\kff\subversion-trunk>
>
> (In that quoted diff output, I have replaced literal CR characters
> with "^M", just to avoid mailers munging it.)
>
> Some interesting things about that diff output:
>
> In the headers, it uses forward slashes. I guess that makes sense;
> that's what 'patch' expects, after all. But this means that in the
> nested function in diff_tests.py:diff_base_to_repos()
>
> def convert_lines(lines):
> return [x.replace("/", os.path.sep).replace("\n", os.linesep)
> for x in lines]
>
> ...at least the first replacement is wrong. (Mea culpa. I can fix
> that pretty easily, anyway.)
>
> However, the weirder thing is that the diff consistently has CRLF on
> the ends of the header lines, but LF on the ends of the diff hunk
> portions, *no matter whether svn:eol-style is set to native or not*.
>
Our diff library doesn't handle eol-styles other than LF (and native,
where that's the same) very well. I've added some discussion about that in
notes/diff-encodings.txt.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 30 22:52:12 2005