On Sat, Oct 15, 2011 at 8:25 AM, Daniel Shahaf <d.s_at_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.
Received on 2011-10-15 16:23:42 CEST