On Oct 14, 2011, at 18:52, Johan Corveleyn wrote: > Ah, but git-svn doesn't seem to honor the invariant that files with > native eol-style *must* be converted to LF by the client. By not doing > this, they break things for every other svn client using the same > repository. So this is clearly a bug in git-svn. Of course, to avoid > flames, we should probably first escalate the problem to the git-svn > people, to get this bug fixed (or maybe it is already fixed?).
It's not just the svn:eol-style conversion that git-svn doesn't do; I hear it doesn't do svn:keywords normalizations either. It's the responsibility of the client to ensure that, for example "$Id: foo bar baz $" gets normalized to "$Id$" before being sent to the repository to be committed. I was told that the git people don't believe in the kind of munging that Subversion does for eol-style and keywords and therefore they don't want to implement it. I say fix the server to issue an error when a client tries to commit data that is not normalized in the required fashion. Force them to comply, and stop distributing software that does not behave correctly. Until the server is fixed to do this, a hook like the below should be used. >> 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). When svn:eol-style is set to ANY value, the file is stored in the repository with LF line endings, and converted to the desired EOL style by the client on checkout or export (and converted by the client to LF line endings before being committed).
