> 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 <[email protected]>: > 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 <[email protected]>: > 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 <[email protected]>: > 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 <[email protected]>: > 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
