Re: svn client does not convert line endings for some java files
From: Marek Slama <mslama_at_email.cz>
Date: Fri, 03 May 2013 15:57:29 +0200 (CEST)
So it seems I will have to set eol-style explicitly on all my text files. I
will have to investigate how to set eol-style
for newly added file for different clients my teammates use on Win. On Linux
I can set it in config file using auto-props.
Thanks for info
Marek
---------- Původní zpráva ----------
Od: C. Michael Pilato <cmpilato_at_collab.net>
Datum: 3. 5. 2013
Předmět: Re: svn client does not convert line endings for some java files
"On 05/03/2013 09:21 AM, Marek Slama wrote:
> Hi,
>
> not sure why but my svn client does not convert line endings for 'some'
> of my files. I did not find any rule for this. I have java project and
> files are text java sources. There is no mime type or eol-style property
> set on given files and some are with Linux line endings and some with DOS
> line endings. I have svn, version 1.7.5 (r1336830) compiled Sep 28 2012,
> 11:22:04. I do not know how to find out server version in case it is
> relevant.
>
> If I set eol-style property to native then it works. But such behaviour
> seems weird to me.
Subversion is designed with a pretty clear policy governing such matters:
don't screw up the user's files!
If you happen to be coming from a CVS background, this will seem odd to you,
because CVS's default mode of operation is to assume that a file is
human-readable and that native newlines are desired, and will quite happily
destroy the binary files you forget to add with the -kb flag.
In Subversion, your file's contents are considered sacred. Unless you set
the svn:eol-style property on a given file, well-behaved Subversion clients
will not attempt to perform newline translation on that file.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development"--=_04bd6b1210d4e8427da4379d;21073d-1234-58da-be54-d76b8af8393e_Content-Type: text/html;
<html><body>So it seems I will have to set eol-style explicitly on all my text files. I will have to investigate how to set eol-style<br>for newly added file for different clients my teammates use on Win. On Linux I can set it in config file using auto-props.<br><br>Thanks for info<br><br>Marek<br><br><br><p>---------- Původní zpráva ----------<br>Od: C. Michael Pilato <cmpilato_at_collab.net><br>Datum: 3. 5. 2013<br>Předmět: Re: svn client does not convert line endings for some java files</p><br><blockquote>On 05/03/2013 09:21 AM, Marek Slama wrote:<br>> Hi,<br>> <br>> not sure why but my svn client does not convert line endings for 'some'<br>> of my files. I did not find any rule for this. I have java project and<br>> files are text java sources. There is no mime type or eol-style property<br>> set on given files and some are with Linux line endings and some with DOS<br>> line endings. I have svn, version 1.7.5 (r1336830) compiled Sep 28 2012,<br>> 11:22:04. I do not know how to find out server version in case it is<br>> relevant.<br>> <br>> If I set eol-style property to native then it works. But such behaviour <br>> seems weird to me.<br><br>Subversion is designed with a pretty clear policy governing such matters:<br>don't screw up the user's files!<br><br>If you happen to be coming from a CVS background, this will seem odd to you,<br>because CVS's default mode of operation is to assume that a file is<br>human-readable and that native newlines are desired, and will quite happily<br>destroy the binary files you forget to add with the -kb flag.<br><br>In Subversion, your file's contents are considered sacred. Unless you set<br>the svn:eol-style property on a given file, well-behaved Subversion clients<br>will not attempt to perform newline translation on that file.<br><br>-- <br>C. Michael Pilato <cmpilato_at_collab.net><br>CollabNet <> www.collab.net <> Enterprise Cloud Development</blockquote></body></html>--=_04bd6b1210d4e8427da4379d;21073d-1234-58da-be54-d76b8af8393e_=--
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.