Johan Corveleyn wrote on Sat, Oct 15, 2011 at 01:52:32 +0200: > On Fri, Oct 14, 2011 at 4:56 PM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > > Johan Corveleyn wrote on Fri, Oct 14, 2011 at 16:25:46 +0200: > >> 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), ... > I think it would be a good thing if the server protected against bugs > in clients by checking this invariant (in the spirit of "don't trust > anything that comes from the client"). > > >> - 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 that's also a possible solution. Though I'm wondering if this
It's a solution to a different problem. One thing is "clients protecting themselves from rogue/buggy servers", and another is "servers protecting themselves from rogue/buggy clients". > would be sufficient: you can also see the problem just by diffing > between repository URL's / revisions (if you "svnlook diff -c REV" one > of those commits, you'll get a full-file diff, although the eol-style > property wasn't changed; that's not nice). Of course, one could make > "svnlook diff" etc. compensate for this too, but that really feels as > some sort of repository corruption which we're papering over. > > >> - 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 > > Thanks. Seems I can experiment a bit with that. Though I think the > problem is specific to eol-style=native (not any eol-style). I thought > that the "conversion-to-LF" only happens for native, and not for > svn:eol-style=LF or svn:eol-style=CRLF (I thought in that case the LF, > or CRLF was saved "as is" in the repository). But I haven't checked > that (we only use native). > You were right; see elsethread. > -- > Johan
