RE: svn:eol-style native and reintegrate merge

I've got to the bottom of this now, sort of. Bottom line is that 1.7 seems fine after all. Even though all the files changed to UNIX line endings, when I committed them they flipped back to windows in my working copy. I think that that is very weird and disconcerting behaviour, and it didn't happen in all the repositories I tested this in (which is also weird and disconcerting). I still think there's an issue here and it could be improved but at the end of the day everything seemed to turn out OK. Is there some repo side config that could affect this?
________________________________________
From: James French [James.French_at_naturalmotion.com]
Sent: 05 October 2012 12:59
To: users_at_subversion.apache.org
Subject: RE: svn:eol-style native and reintegrate merge

http://svn.apache.org/viewvc?view=revision&revision=1355703

Fix a bug in propset which could prevent updating cached values related
   to EOL expansion in wc.db.
   Justification:
     Incorrect behaviour, subtle working copy corruption.
   Votes:
     +1: stsp, rhuijben, philip

This was a 1.7.6 fix and it sounds scarily pertinent....

________________________________________
From: James French [James.French_at_naturalmotion.com]
Sent: 05 October 2012 09:58
To: users_at_subversion.apache.org
Subject: RE: svn:eol-style native and reintegrate merge

________________________________________
From: James French [James.French_at_naturalmotion.com]
Sent: 04 October 2012 22:39
To: users_at_subversion.apache.org
Subject: svn:eol-style native and reintegrate merge

Hi,

Using svn 1.7.6 and working on a dev branch I wrote a script to set svn:eol-style=native on all source code files, because we develop on Mac and PC. When I tried to check in it kept failing on files that had inconsistent line endings so I kept fixing them until I was able to check in. So far so good. The diff of the checkin showed that files with consistent line endings (99% of them) simply had the svn:eol-style=native property on them which is what I expected. Now that I come to reintegrate however I have had a shock - it has converted all files to unix line endings (and I'm on a PC). We do our sync up merges with the --ignore-eol-style style switch (to be honest I'm not sure exactly what this does). I tried reintegrating with and without switch and it does the same - everything has unix line endings. Maybe its just some weird glitch and it won't really change the line endings but I'm too scared to check in to find out. Tomorrow I'm going to try with 1.6 and see what that does.

What the hell is going on?

Cheers,
James

Thanks Thorsten for your reply, replying here for simplicity. It is primarily a windows codebase and all source code has always had windows line endings. I am thoroughly confused. I tried the reintegrate merge with svn 1.6.18. With --ignore-eol-style the merge went through with no conflicts and the files in my working copy all still had windows line endings (as it should be). However, when I did a diff it still showed every line of every file as having changed, even though there was no physical difference on disk. When I diff with --ignore-eol-style only the svn:eol-style native property changes show up. Why is the diff showing line changes? I guess its because its telling me that the internal data has been changed to LF line endings. Fair enough. Still seems weird that a working copy diff should show this though. I still wonder whether this whole native eol thing is going to bite me in the arse later and cause a load of conflicts that rattle around the codebase for ages (over the years svn has unfortunatel
y taught me to expect this kind of stuff).

What I don't accept though is that svn 1.7 is performing correctly. The merge *physically changed* all the source files in my working copy to LF line endings on a windows boc. That *cannot* be right.

James
Received on 2012-10-05 15:15:38 CEST