On Sat, Oct 15, 2011 at 8:25 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Johan Corveleyn wrote on Sat, Oct 15, 2011 at 01:52:32 +0200:
>> 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. Perhaps a better approach, especially if you know people will be using git-svn, is to review the repository for any files that use svn:eol, and *turn that off*, with a check that the binary EOL is the format you want. Then put in a pre-commit hook to prevent anyone using it. I've had to do this to block svn:keywords for environments where the git-svn clients inability to update $Id$ and $HeadURL$ caused heartache and conflict for other developers who expected to be able to run checksums or to establish the provenance of the deployed file, based on that data. Frankly, I agree with git's approach on this. If it's causing fragility or confusion, and the EOL processing and keyword processing make this inevitable in many environments, *turn it off*. This is especially true with multi-platform access to the same working copy, such as CygWin and Windows, or CIFS shared working copies. And when I seen a $Id$ or "HeadURL$" tag that is inside a local configuration modified configuration file being pushed elsewhere, the keyword is a *lie*. It's why I'm very careful to have the local file, such as "httpd.conf", stored in Subversion as "httpd.conf.in" and "svn:ignore" set to never commit those locally updated files.
