[webkit-reviews] review requested: [Bug 27323] Better support for non-Cygwin SVN on Windows : [Attachment 32992] Fixes, part 6

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jul 17 17:59:13 PDT 2009


Peter Kasting <pkasting at google.com> has asked David Kilzer (ddkilzer)
<ddkilzer at webkit.org> for review:
Bug 27323: Better support for non-Cygwin SVN on Windows
https://bugs.webkit.org/show_bug.cgi?id=27323

Attachment 32992: Fixes, part 6
https://bugs.webkit.org/attachment.cgi?id=32992&action=review

------- Additional Comments from Peter Kasting <pkasting at google.com>
This makes resolve-ChangeLogs work significantly better for non-Cygwin SVNs.

One concern I have is my usage of --binary.  Without this, the ChangeLog files
were being converted from CRLF (how they were checked out) to LF by patch,
except for the new local changes, which were preserved as CRLF, leaving the
ChangeLogs in a mixed state.  I _think_ it should be safe on all platforms to
use --binary here to tell diff and patch to treat line endings as a black box
and not modify them, but I admit it's not what happens in svn-create-patch,
svn-apply, svn-unapply, etc., which (on my non-Cygwin SVN system) currently
strip CRs from everywhere (resulting in files whose line endings are completely
changed, which doesn't bother svn if the files have an svn:eol-style set).  I'm
concerned that if I add more usage of --binary to all these scripts that files
checked out with eol-style "native" and then modified will result in patches
which can't be cleanly applied on OSes different from the one which created
them.  By contrast, the changes here only affect the internal workings of
resolve-ChangeLogs, so they can't cause such problems, unless the local
ChangeLogs have mixed endings before running resolve-ChangeLogs.

What a mess.


More information about the webkit-reviews mailing list