> Konstantin Kolinko wrote on Fri, Oct 14, 2011 at 17:43:03 +0400:
>> 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.
>>
>>
>> AFAIK such files are stored with LF endings at the server. Is this
>> line endings convention enforced on the client only?
>>
>> I am on Windows. Both
>> svn cat http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java@1183339
>> svn cat http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java@1183340
>>
>> produce files with CRLF endings for me, so I do not see such huge
>> difference between the files.
>>
>> But diff command below does produces that huge diff, that is shown by
>> viewvc and was in the commit email:
>>
>> svn diff -c 1183340
>> http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
>>
>>
>> Besides the diff I do not have other evidence that the file in
>> repository has CRs or is otherwise broken.
>>
2011/10/14 Daniel Shahaf <d.s_at_daniel.shahaf.name>:
> The file has CR's in r1183340 but not in r1183339. Yes, since it has
> svn:eol-style set, it is supposed to be stored in LF on the server.
Thank you for confirming. I also found a way to confirm:
http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?p=1183339
vs
http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?p=1183340
The second one has CRLFs, the first one LFs.
I reverted the file to LFs in r1183612
(by submitting a non-changed file with TortoiseSVN)
2011/10/15 Ryan Schmidt <subversion-2011a_at_ryandesign.com>:
> 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.
I cannot confirm the issue with keywords.
Both files returned by http:// above have $Id$ in them.
I guess that Git did not expand $Id$, so it remained as it was in the
original file.
2011/10/14 Johan Corveleyn <jcorvel_at_gmail.com>:
> It does cause a lot of problems though. The files show up as Modified
> in "svn status",
Confirming.
It is displayed as modified, but to observe this you have to touch the file.
(Otherwise subversion does not compare the file with its svn-base)
Using 1.7.0, WindowsXP.
2011/10/14 Daniel Shahaf <d.s_at_daniel.shahaf.name>:
> 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
>
Good, impressive.
As others noted, one has to check for specific values of svn:eol-style
(native, LF), so "svnlook propget" instead of proplist will be needed.
I am not sure about && [ "`...`" ]. Maybe && [ -n "`...`" ] to test
for non-empty strings.
A friendly error message wouldn't hurt either.
Best regards,
Konstantin Kolinko
Received on 2011-10-15 12:28:17 CEST