On Fri, Oct 14, 2011 at 3:54 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Oct 14, 2011 at 05:43:03PM +0400, Konstantin Kolinko wrote:
>> Hi!
>>
>> One of committers in Apache Tomcat project is experimenting with Git
>> <-> Subversion integration.
>>
>> A result is that in the last few days several commits produced diffs
>> for entire file. An example:
>>
>> http://svn.apache.org/viewvc?view=revision&revision=1183340
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?r1=1183339&r2=1183340
>>
>> Commit e-mail:
>> http://markmail.org/message/f4rdxrjvrenc6tg6
>> http://markmail.org/message/iysr4bsfckegq7vp
>>
>> How can this happen from subversion point of view?
>> The file has svn:eol-style=native.
>
> Because whichever git integratio is used ignores this setting and
> commits all with lines CRLF anyway?
>
>> AFAIK such files are stored with LF endings at the server. Is this
>> line endings convention enforced on the client only?
>
> Yes. The client changes the file EOLs whenever the local value of the
> svn:eol-style property changes.
>
> Recall that the server uses binary diffs.
> It doesn't know or care what a newline is.
I've seen this problem too at my company (also probably related to the
use of git-svn (or perhaps also by using the svn package of cygwin,
but I'm not sure about that). I've since repaired the files with
"corrupt eols", and didn't have time to investigate further.
It does cause a lot of problems though. The files show up as Modified
in "svn status", and "svn diff" shows all lines as modified (but "svn
diff -x--ignore-eol-style" doesn't of course). If users commit the
"modification", the eol-corruption is repaired. These "modified" files
can also cause tree conflicts (which can generate quite some WTF's).
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.
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.
- Currently the client is the sole responsible to do this, but a
broken client can break a lot of things for all other users.
- Maybe as a workaround: can someone come up with a hook script for
checking this situation in a pre-commit hook?
--
Johan
Received on 2011-10-14 16:26:39 CEST