Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of
 James.French@naturalmotion.com designates 86.12.140.205 as permitted sender)
From: James French <James.French@naturalmotion.com>
To: "users@subversion.apache.org" <users@subversion.apache.org>
Date: Fri, 5 Oct 2012 12:59:14 +0100
Subject: RE: svn:eol-style native and reintegrate merge
Thread-Topic: svn:eol-style native and reintegrate merge
Thread-Index: AQHNoni3SpjgCFKOxESL9RaTUE3nNJeqZpFHgAA2K0A=
Message-ID: <950618E0D00138499BE7CC487EBF646D787C047D28@WOODCHUCK.NM.local>
References: 
 <950618E0D00138499BE7CC487EBF646D787C047D18@WOODCHUCK.NM.local>,<950618E0D00138499BE7CC487EBF646D787C047D1B@WOODCHUCK.NM.local>
In-Reply-To: <950618E0D00138499BE7CC487EBF646D787C047D1B@WOODCHUCK.NM.local>
Accept-Language: en-US, en-GB
Content-Language: en-GB
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

http://svn.apache.org/viewvc?view=3Drevision&revision=3D1355703

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@naturalmotion.com]
Sent: 05 October 2012 09:58
To: users@subversion.apache.org
Subject: RE: svn:eol-style native and reintegrate merge

________________________________________
From: James French [James.French@naturalmotion.com]
Sent: 04 October 2012 22:39
To: users@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=3Dnative 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 li=
ne endings so I kept fixing them until I was able to check in. So far so go=
od. The diff of the checkin showed that files with consistent line endings =
(99% of them) simply had the svn:eol-style=3Dnative property on them which =
is what I expected. Now that I come to reintegrate however I have had a sho=
ck - 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 hones=
t I'm not sure exactly what this does). I tried reintegrating with and with=
out switch and it does the same - everything has unix line endings. Maybe i=
ts 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 a=
nd see what that does.

What the hell is going on?

Cheers,
James


Thanks Thorsten for your reply, replying here for simplicity.  It is primar=
ily a windows codebase and all source code has always had windows line endi=
ngs. I am thoroughly confused. I tried the reintegrate merge with svn 1.6.1=
8. 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 chan=
ges 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 codeba=
se for ages (over the years svn has unfortunately taught me to expect this =
kind of stuff).

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

James