[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: Win32 test failures
From:       "Peter N. Lundblad" <peter () famlundblad ! se>
Date:       2005-06-30 20:44:30
Message-ID: Pine.LNX.4.55.0506302242000.8218 () localhost ! localdomain
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]