You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Norbert Unterberg <nu...@gmail.com> on 2008/06/17 13:53:37 UTC
Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
One of my collegues gets strange merge conflicts while using his svn
1.4 client after I checked in some changes. The files all have
svn:eol-style set to "native". The server is still running on svn
1.3.2
Analysis showed that svn 1.4 clients always stored the text file in LF
encoding regardless of the eol-style. The file in the wc itself is
correctly stored in CRLF style on Windows.
However, after commiting with my 1.5 client and updating with 1.4 on
the other machine, the files in the text-base were also stored in CRLF
style. When merging, this generates merge conflicts for the entiere
file because every line is different.
If this is problem is still present in the current RC, I'd say this
could be a release blocker since it breaks all the older clients
working copies....
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Jun 17, 2008 at 10:41 AM, Norbert Unterberg
<nu...@gmail.com> wrote:
> We are just planning to upgrade together with a Trac upgrade in a few weeks.
> But are you saying that 1.5 clients are no longer compatible with 1.3 servers?
Tigris is still running 1.3 and I do most of my work on Tigris. I
have been using "1.5" client since last summer and have never seen
this. I use it for Subclipse development and I set svn:eol-style
native via autoprops for all text files.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Norbert Unterberg <nu...@gmail.com>.
On Tue, Jun 17, 2008 at 4:56 PM, John Peacock
<jo...@havurah-software.org> wrote:
> Norbert Unterberg wrote:
>>
>> Unfortunately I have never used svnlook on the server side so I can
>> not be sure, but a svn diff with the 1.4 client shows all lines as
>> changed.
>
> Use 'svn cat http://server/path/to/file > file.server' to dump out exactly
> what the server thinks it has. You could also check out the containing
> directory using the 1.5 client in some temporary folder, to see what the
> text-base looks like (just running 'svn up' in the old checkout won't do you
> any good because the working copy is already up to date).
RIght before I left the office I had a chance to do a svnlook diff
-r3544 (the revision I commited the file in question). The svnlook
diff shows the complete file as changed and not only the three lines I
changed, so I am still very sure the CRLF did make it into the
repository regardless of the LF only text-base.
Since I am no longer in the office I can not do more tests today.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks
version 1.4 wc
Posted by John Peacock <jo...@havurah-software.org>.
Norbert Unterberg wrote:
> Unfortunately I have never used svnlook on the server side so I can
> not be sure, but a svn diff with the 1.4 client shows all lines as
> changed.
Use 'svn cat http://server/path/to/file > file.server' to dump out
exactly what the server thinks it has. You could also check out the
containing directory using the 1.5 client in some temporary folder, to
see what the text-base looks like (just running 'svn up' in the old
checkout won't do you any good because the working copy is already up to
date).
>> Regardless of these answers, I would strongly recommend that you convert the
>> server to 1.4.6 at your earliest convenience; 1.3.2 is very old and there
>> have been numerous improvements since then (not the least of which is
>> improved storage compression). You will need to do a dump/reload to do
>> this...
>
> We are just planning to upgrade together with a Trac upgrade in a few weeks.
> But are you saying that 1.5 clients are no longer compatible with 1.3 servers?
No, I'm saying that 1.4 or better clients work *better* with 1.4 or
better servers. There are backend storage changes, over the wire
compression changes, and better streaminess (fewer roundtrips) with
newer client/servers. All newer 1.x clients are required to maintain
interoperability with older 1.x servers (the obverse is also true, newer
1.x servers work with older 1.x clients). The newer clients just work
better with the newer server.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Norbert Unterberg <nu...@gmail.com>.
On Tue, Jun 17, 2008 at 4:20 PM, John Peacock
<jo...@havurah-software.org> wrote:
> Norbert Unterberg wrote:
>>
>> However, after commiting with my 1.5 client and updating with 1.4 on
>> the other machine, the files in the text-base were also stored in CRLF
>> style. When merging, this generates merge conflicts for the entiere
>> file because every line is different.
>
> Are you using a shared working copy by any chance? Were the files marked
> svn:eol-style "native" before your commit with the 1.5 client? If the answer
> to the first question is "No", are the text-base files in the 1.5 working
> copy LF or CRLF?
No shared WC at all, all on my local hard drive.
The svn:eol-style was not changed during the commit.
The text-base files in the 1.5 wc are LF only, but it seems that they
are CRLF in the repository.
Unfortunately I have never used svnlook on the server side so I can
not be sure, but a svn diff with the 1.4 client shows all lines as
changed.
> Regardless of these answers, I would strongly recommend that you convert the
> server to 1.4.6 at your earliest convenience; 1.3.2 is very old and there
> have been numerous improvements since then (not the least of which is
> improved storage compression). You will need to do a dump/reload to do
> this...
We are just planning to upgrade together with a Trac upgrade in a few weeks.
But are you saying that 1.5 clients are no longer compatible with 1.3 servers?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks
version 1.4 wc
Posted by John Peacock <jo...@havurah-software.org>.
Norbert Unterberg wrote:
> However, after commiting with my 1.5 client and updating with 1.4 on
> the other machine, the files in the text-base were also stored in CRLF
> style. When merging, this generates merge conflicts for the entiere
> file because every line is different.
Are you using a shared working copy by any chance? Were the files
marked svn:eol-style "native" before your commit with the 1.5 client?
If the answer to the first question is "No", are the text-base files in
the 1.5 working copy LF or CRLF?
Regardless of these answers, I would strongly recommend that you convert
the server to 1.4.6 at your earliest convenience; 1.3.2 is very old and
there have been numerous improvements since then (not the least of which
is improved storage compression). You will need to do a dump/reload to
do this...
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Norbert Unterberg <nu...@gmail.com>.
On Tue, Jun 17, 2008 at 10:40 PM, David Glasser
<gl...@davidglasser.net> wrote:
> On Tue, Jun 17, 2008 at 6:53 AM, Norbert Unterberg <nu...@gmail.com> wrote:
>> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>>
>> One of my collegues gets strange merge conflicts while using his svn
>> 1.4 client after I checked in some changes. The files all have
>> svn:eol-style set to "native". The server is still running on svn
>> 1.3.2
>> Analysis showed that svn 1.4 clients always stored the text file in LF
>> encoding regardless of the eol-style. The file in the wc itself is
>> correctly stored in CRLF style on Windows.
>>
>> However, after commiting with my 1.5 client and updating with 1.4 on
>> the other machine, the files in the text-base were also stored in CRLF
>> style. When merging, this generates merge conflicts for the entiere
>> file because every line is different.
>>
>> If this is problem is still present in the current RC, I'd say this
>> could be a release blocker since it breaks all the older clients
>> working copies....
>
> Norbert, this does seem like a problem.
>
> Can you give us a detailed recipe that consistently reproduces it?
I can no longer duplicate that problem.
In addition, the TSVN version I used when doing that "bad" commit was
a very early nightly built, probably a few months old. I upgraded to
the RC3 right after that commit, so I think that the current 1.5 is
not responsible.
I am sorry for panicking and apologize for the noise I produced on
this list, and wish you a successful Subversion release.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Norbert Unterberg <nu...@gmail.com>.
On Tue, Jun 17, 2008 at 10:44 PM, Norbert Unterberg
<nu...@gmail.com> wrote:
> On Tue, Jun 17, 2008 at 10:40 PM, David Glasser
> <gl...@davidglasser.net> wrote:
>> On Tue, Jun 17, 2008 at 6:53 AM, Norbert Unterberg <nu...@gmail.com> wrote:
>>> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>>>
>>> One of my collegues gets strange merge conflicts while using his svn
>>> 1.4 client after I checked in some changes. The files all have
>>> svn:eol-style set to "native". The server is still running on svn
>>> 1.3.2
>>> Analysis showed that svn 1.4 clients always stored the text file in LF
>>> encoding regardless of the eol-style. The file in the wc itself is
>>> correctly stored in CRLF style on Windows.
[...]
>> Norbert, this does seem like a problem.
>>
>> Can you give us a detailed recipe that consistently reproduces it?
[..]
> I thought that this might come up, but unfortunately I am no longer in
> the office where it happened. I'll try to do my best to reproduce it
> here on my home pc.
I can not duplicate it here with file:// access. I will try tomorrow
on the "real" server in the office,
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Norbert Unterberg <nu...@gmail.com>.
On Tue, Jun 17, 2008 at 10:40 PM, David Glasser
<gl...@davidglasser.net> wrote:
> On Tue, Jun 17, 2008 at 6:53 AM, Norbert Unterberg <nu...@gmail.com> wrote:
>> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>>
>> One of my collegues gets strange merge conflicts while using his svn
>> 1.4 client after I checked in some changes. The files all have
>> svn:eol-style set to "native". The server is still running on svn
>> 1.3.2
>> Analysis showed that svn 1.4 clients always stored the text file in LF
>> encoding regardless of the eol-style. The file in the wc itself is
>> correctly stored in CRLF style on Windows.
>>
>> However, after commiting with my 1.5 client and updating with 1.4 on
>> the other machine, the files in the text-base were also stored in CRLF
>> style. When merging, this generates merge conflicts for the entiere
>> file because every line is different.
>>
>> If this is problem is still present in the current RC, I'd say this
>> could be a release blocker since it breaks all the older clients
>> working copies....
>
> Norbert, this does seem like a problem.
>
> Can you give us a detailed recipe that consistently reproduces it?
>
> Without that, we're reduced to asking little questions step by step
> like we have been for the past few hours, which really isn't
> productive :-)
I thought that this might come up, but unfortunately I am no longer in
the office where it happened. I'll try to do my best to reproduce it
here on my home pc.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by David Glasser <gl...@davidglasser.net>.
On Tue, Jun 17, 2008 at 6:53 AM, Norbert Unterberg <nu...@gmail.com> wrote:
> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>
> One of my collegues gets strange merge conflicts while using his svn
> 1.4 client after I checked in some changes. The files all have
> svn:eol-style set to "native". The server is still running on svn
> 1.3.2
> Analysis showed that svn 1.4 clients always stored the text file in LF
> encoding regardless of the eol-style. The file in the wc itself is
> correctly stored in CRLF style on Windows.
>
> However, after commiting with my 1.5 client and updating with 1.4 on
> the other machine, the files in the text-base were also stored in CRLF
> style. When merging, this generates merge conflicts for the entiere
> file because every line is different.
>
> If this is problem is still present in the current RC, I'd say this
> could be a release blocker since it breaks all the older clients
> working copies....
Norbert, this does seem like a problem.
Can you give us a detailed recipe that consistently reproduces it?
Without that, we're reduced to asking little questions step by step
like we have been for the past few hours, which really isn't
productive :-)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Norbert Unterberg <nu...@gmail.com>.
On Tue, Jun 17, 2008 at 4:36 PM, John Peacock
<jo...@havurah-software.org> wrote:
> Norbert Unterberg wrote:
>>
>> Who performs the CRLF to LF conversion during a commit, the server or
>> the client?
>
> The client code performs any conversions (from the local text-base, which is
> an exact representation of what the server sent). This is because there may
> be keyword substitution going on as well.
>
> The server normally stores the files as LF, but you can get into a state
> where files contain CRLF, but this is usually caused by external tools
> messing with the line endings when they shouldn't.
>
>> It seems that the 1.5 client sent the file including the CRLF to the
>> server instead of converting to LF during commit. A svn diff of the
>> changed file shows the eol-style change for each line. I still need to
>> verify that that CRLF are really present on the server.
>
> If the diff is showing that the EOL changed for each line, it is definitely
> the client that is at fault (but not necessarily the Subversion client). It
> could just have easily been Tortoise...
That is very strange. The svn diff was using the svn 1.4.3 command
line client. However, the commit was done using TSVN 1.5 rc3. I'll
better report the problem there, too.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks
version 1.4 wc
Posted by John Peacock <jo...@havurah-software.org>.
C. Michael Pilato wrote:
> Unless I'm mistaken, this is inaccurate.
> Files with svn:eol-style set to 'native' are stored in the repository
> with 'LF'-style line endings, so that successive commits from different
> OSes don't repeatedly cause every-line-changed-line-endings types of
> churn in the file's versioned contents.
Yes, I'm sorry, I was assuming we were still talking about 'native'
svn:eol-style. I should have been more explicit...
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks
version 1.4 wc
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock wrote:
> Norbert Unterberg wrote:
>> Who performs the CRLF to LF conversion during a commit, the server or
>> the client?
>
> The client code performs any conversions (from the local text-base,
> which is an exact representation of what the server sent). This is
> because there may be keyword substitution going on as well.
>
> The server normally stores the files as LF, but you can get into a state
> where files contain CRLF, but this is usually caused by external tools
> messing with the line endings when they shouldn't.
Unless I'm mistaken, this is inaccurate.
The server, by default (no svn:eol-style set) stores files in whatever way
they are represented by the committing client.
Files with svn:eol-style set to 'CR', 'LF', or 'CRLF' are stored in the
repository with the specified line ending styles.
Files with svn:eol-style set to 'native' are stored in the repository with
'LF'-style line endings, so that successive commits from different OSes
don't repeatedly cause every-line-changed-line-endings types of churn in the
file's versioned contents.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks
version 1.4 wc
Posted by John Peacock <jo...@havurah-software.org>.
Norbert Unterberg wrote:
> Who performs the CRLF to LF conversion during a commit, the server or
> the client?
The client code performs any conversions (from the local text-base,
which is an exact representation of what the server sent). This is
because there may be keyword substitution going on as well.
The server normally stores the files as LF, but you can get into a state
where files contain CRLF, but this is usually caused by external tools
messing with the line endings when they shouldn't.
> It seems that the 1.5 client sent the file including the CRLF to the
> server instead of converting to LF during commit. A svn diff of the
> changed file shows the eol-style change for each line. I still need to
> verify that that CRLF are really present on the server.
If the diff is showing that the EOL changed for each line, it is
definitely the client that is at fault (but not necessarily the
Subversion client). It could just have easily been Tortoise...
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks
version 1.4 wc
Posted by "C. Michael Pilato" <cm...@collab.net>.
Norbert Unterberg wrote:
> On Tue, Jun 17, 2008 at 3:57 PM, Mark Phippard <ma...@gmail.com> wrote:
>> On Tue, Jun 17, 2008 at 9:53 AM, Norbert Unterberg <nu...@gmail.com> wrote:
>>> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>>>
>>> One of my collegues gets strange merge conflicts while using his svn
>>> 1.4 client after I checked in some changes. The files all have
>>> svn:eol-style set to "native". The server is still running on svn
>>> 1.3.2
>>> Analysis showed that svn 1.4 clients always stored the text file in LF
>>> encoding regardless of the eol-style. The file in the wc itself is
>>> correctly stored in CRLF style on Windows.
>>>
>>> However, after commiting with my 1.5 client and updating with 1.4 on
>>> the other machine, the files in the text-base were also stored in CRLF
>>> style. When merging, this generates merge conflicts for the entiere
>>> file because every line is different.
>>>
>>> If this is problem is still present in the current RC, I'd say this
>>> could be a release blocker since it breaks all the older clients
>>> working copies....
>> I have not observed this. I also do not see how one client could
>> inject a problem on to a different client. The server is responsible
>> for storing the contents and providing it to the other client.
>
> Who performs the CRLF to LF conversion during a commit, the server or
> the client?
The client is responsible for this conversion. The text-base should always
be an exact replica of the repository contents.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Norbert Unterberg <nu...@gmail.com>.
On Tue, Jun 17, 2008 at 3:57 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, Jun 17, 2008 at 9:53 AM, Norbert Unterberg <nu...@gmail.com> wrote:
>> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>>
>> One of my collegues gets strange merge conflicts while using his svn
>> 1.4 client after I checked in some changes. The files all have
>> svn:eol-style set to "native". The server is still running on svn
>> 1.3.2
>> Analysis showed that svn 1.4 clients always stored the text file in LF
>> encoding regardless of the eol-style. The file in the wc itself is
>> correctly stored in CRLF style on Windows.
>>
>> However, after commiting with my 1.5 client and updating with 1.4 on
>> the other machine, the files in the text-base were also stored in CRLF
>> style. When merging, this generates merge conflicts for the entiere
>> file because every line is different.
>>
>> If this is problem is still present in the current RC, I'd say this
>> could be a release blocker since it breaks all the older clients
>> working copies....
>
> I have not observed this. I also do not see how one client could
> inject a problem on to a different client. The server is responsible
> for storing the contents and providing it to the other client.
Who performs the CRLF to LF conversion during a commit, the server or
the client?
It seems that the 1.5 client sent the file including the CRLF to the
server instead of converting to LF during commit. A svn diff of the
changed file shows the eol-style change for each line. I still need to
verify that that CRLF are really present on the server.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Jun 17, 2008 at 9:53 AM, Norbert Unterberg <nu...@gmail.com> wrote:
> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>
> One of my collegues gets strange merge conflicts while using his svn
> 1.4 client after I checked in some changes. The files all have
> svn:eol-style set to "native". The server is still running on svn
> 1.3.2
> Analysis showed that svn 1.4 clients always stored the text file in LF
> encoding regardless of the eol-style. The file in the wc itself is
> correctly stored in CRLF style on Windows.
>
> However, after commiting with my 1.5 client and updating with 1.4 on
> the other machine, the files in the text-base were also stored in CRLF
> style. When merging, this generates merge conflicts for the entiere
> file because every line is different.
>
> If this is problem is still present in the current RC, I'd say this
> could be a release blocker since it breaks all the older clients
> working copies....
I have not observed this. I also do not see how one client could
inject a problem on to a different client. The server is responsible
for storing the contents and providing it to the other client.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Norbert Unterberg <nu...@gmail.com>.
On Tue, Jun 17, 2008 at 4:05 PM, Erik Huelsmann <eh...@gmail.com> wrote:
> On 6/17/08, Norbert Unterberg <nu...@gmail.com> wrote:
>> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>>
>> One of my collegues gets strange merge conflicts while using his svn
>> 1.4 client after I checked in some changes. The files all have
>> svn:eol-style set to "native". The server is still running on svn
>> 1.3.2
>> Analysis showed that svn 1.4 clients always stored the text file in LF
>> encoding regardless of the eol-style. The file in the wc itself is
>> correctly stored in CRLF style on Windows.
>>
>> However, after commiting with my 1.5 client and updating with 1.4 on
>> the other machine, the files in the text-base were also stored in CRLF
>> style. When merging, this generates merge conflicts for the entiere
>> file because every line is different.
>>
>> If this is problem is still present in the current RC, I'd say this
>> could be a release blocker since it breaks all the older clients
>> working copies....
>
> Are you sure the working copy you merged into as well as the merge
> start *and* merge end all had eol-style native? If not, that could be
> the problem.
Yes I am sure. We add the eol-style property via auto-props and never
change them manually.
Even without the merge, the single commit I did on the file pushed the
CRLF into the server, without any change to the eol-style flag.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug (release blocker?): svn 1.5 eol-style:native on windows breaks version 1.4 wc
Posted by Erik Huelsmann <eh...@gmail.com>.
On 6/17/08, Norbert Unterberg <nu...@gmail.com> wrote:
> I am using TortoiseSVN 1.5 rc3 (based on svn 1.5-rc9) on Windows XP.
>
> One of my collegues gets strange merge conflicts while using his svn
> 1.4 client after I checked in some changes. The files all have
> svn:eol-style set to "native". The server is still running on svn
> 1.3.2
> Analysis showed that svn 1.4 clients always stored the text file in LF
> encoding regardless of the eol-style. The file in the wc itself is
> correctly stored in CRLF style on Windows.
>
> However, after commiting with my 1.5 client and updating with 1.4 on
> the other machine, the files in the text-base were also stored in CRLF
> style. When merging, this generates merge conflicts for the entiere
> file because every line is different.
>
> If this is problem is still present in the current RC, I'd say this
> could be a release blocker since it breaks all the older clients
> working copies....
Are you sure the working copy you merged into as well as the merge
start *and* merge end all had eol-style native? If not, that could be
the problem.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org