Johan Corveleyn wrote on Sun, Dec 09, 2012 at 01:02:55 +0100:
> Last week a colleague managed to commit a non-LF-normalized
> svn:eol-style=native file in our repository again. As explained in
> issue #4065 [1], this causes all kinds of problems.
>
> I suspect there might be a bug in SVNKit, some edge-case where it
> doesn't correctly translate the to-be-committed files to
> LF-termination. But regardless, I'd like to protect my repository. I
> don't fully control the clients that people use, and those clients can
> always have bugs, ...
>
> So ... how hard would it be to fix issue #4065, making the server
> enforce the right eol-ness for correct operation? It's a genuine
> question, I have no idea :-).
>
for i in $(svnlook changed -t $TXN $REPOS); do
if propget = native || propget = LF ; then
svnlook cat -t $TXN $REPOS $i | xxd -c1 -p | grep -i 0d
fi
done
And writing that made me realise... "contains CR" is such a simple
condition, that you don't need the fulltext for it --- you would be able
to implement it by looking at the "literal new text" segments within
svndiff streams directly. However, I'm not quite sure whether this
observation is the key to a simple implementation or to an
unnecessarily-complicated one.
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4065 - server
> should enforce LF normalization for svn:eol-style=native files
>
> --
> Johan
Received on 2012-12-09 09:14:42 CET