[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ^M Appends to every line?

From: Tony Butt <Tony.Butt_at_cea.com.au>
Date: Thu, 24 Feb 2011 13:38:46 +1100

On Wed, 2011-02-23 at 20:03 -0600, Ryan Schmidt wrote:
> On Feb 23, 2011, at 19:48, David Chapman wrote:
> > On 2/23/2011 4:44 PM, Nico Kadel-Garcia wrote:
> >> On Wed, Feb 23, 2011 at 11:39 AM, Les Mikesell wrote:
> >>> Short version: set the svn:eol-style property to native on the files where
> >>> you want subversion to manage line endings. Your client may have a list of
> >>> file suffixes where this would be set automatically.
> >> But in general, avoid it. If you're in a mixed platform environment,
> >> and you are tweaking files back and forth in end-of-line settings when
> >> you check them out in UNIX versis checking them out in Windows, you
> >> are in for a *world* of hurt. This is a source of enormous confusion
> >> for programmers when it works right, on one system, but not on the
> >> other due to local re-writing.
> >>
> >> If you're on the UNIX or Linux sides, the "dos2unix" and "unix2dos"
> >> utilities are available with almost every distribution. For Windows,
> >> there are other tools, including the same tools under CygWin.
> >
> > Uh, no. Use of "svn:eol-style" avoids a world of hurt - programmers do not have to run a script *every* time they check out a file. Requiring users to run a script to fix line endings in every sandbox is a recipe for disaster.
> >
> > "dos2unix" and "unix2dos" are precisely the kind of local rewriting you want to avoid.
>
>
> Some have the view that setting svn:eol-style to native is a problem; perhaps that's what Nico meant. Certainly, it would be a problem (wouldn't work as designed) if you check out a working copy on a platform with one eol convention (e.g. Mac OS X) and move that working copy to an OS with a different eol convention (e.g. Windows). If that is something you plan to do, the alternative is to still use svn:eol-style but set it to a specific eol style instead -- for example LF. Then you would have to configure all your editors on all platforms to use that line ending style.*
>
> * Actually it does not matter if the editor decided, for example, to completely convert the file from, say, LF to CRLF line endings. On commit, your Subversion client would notice the change and convert it back to just LF before submitting it to the repository. The situation Subversion won't handle for you, and will abort the commit with an error message, is if your editor decides to save a file with mixed line endings. Such editors are broken IMHO. UltraEdit is an example of an editor we used which was broken in this way, unless you remembered to change a particular preference setting.
Another example is emacs (the one true ring (um) editor). But only if
there were mixed line endings to begin with.
>
> NOT using svn:eol-style at all will remove all eol checks that Subversion does, and if you are using multiple editors on multiple platforms, you will most probably end up with files of mixed line ending styles. THAT is a recipe for disaster.
>
I have in the past tried to use a smb exported share form a unix box on
a windows client. Don't do that, nothing but trouble.
>

-- 
Tony Butt <Tony.Butt_at_cea.com.au>
CEA Technologies
Received on 2011-02-24 03:40:33 CET

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.