Johan Corveleyn wrote on Fri, Oct 14, 2011 at 16:25:46 +0200:
> These "modified" files can also cause tree conflicts (which can
> generate quite some WTF's).
>
Tree conflicts? How? I'd have expected (full-file) text conflicts only.
> You can identify the corrupt files easily by taking a look at the
> corresponding pristine files (or .svn-base files in .svn/text-base).
> They will have CRLF, while "correct" files with eol-style native
> should only have LF in the pristine file.
>
Nice. I did wonder about that, since 'svn cat' silently transform the EOLs.
> This makes me wonder:
> - Why can't the server verify that files with native eol-style are
> committed to the repository with LF line-termination? That would seem
> like a very sane validation.
It's possible. If we do this we'll (a) cause files in existing
repositories to be uncommittable by tools that don't convert to LF
before committing (this does _not_ include the 'svn' client, and
probably doesn't include anything that goes through libsvn_client),
(b) probably get some flames along the lines of "The svn devs broke
git-svn on purpose". :P
> - Currently the client is the sole responsible to do this, but a
> broken client can break a lot of things for all other users.
Yep. And along the same lines, the client may want to force EOL
canonicalization in code paths that currently just assume that the
server will provide files with the correct EOL styles.
> - Maybe as a workaround: can someone come up with a hook script for
> checking this situation in a pre-commit hook?
>
for f in $CHANGED_FILES; do
if svnlook pl -t $txn $repos $f | grep -w svn:eol-style >/dev/null && [
"`svnlook cat -t $txn $repos $f | xxd -ps -c1 | fgrep 0d | head -n1`" ]; then
exit 1
fi
done
> --
> Johan
