Return-Path: Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: (qmail 96174 invoked from network); 24 Feb 2011 16:02:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Feb 2011 16:02:44 -0000 Received: (qmail 61762 invoked by uid 500); 24 Feb 2011 16:02:43 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 61602 invoked by uid 500); 24 Feb 2011 16:02:40 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 61595 invoked by uid 99); 24 Feb 2011 16:02:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Feb 2011 16:02:40 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS,TVD_FW_GRAPHIC_NAME_MID X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cdhaakin@us.ibm.com designates 32.97.182.138 as permitted sender) Received: from [32.97.182.138] (HELO e8.ny.us.ibm.com) (32.97.182.138) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Feb 2011 16:02:33 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1OBhcZC028909 for ; Thu, 24 Feb 2011 06:43:38 -0500 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1OG2BUq337278 for ; Thu, 24 Feb 2011 11:02:11 -0500 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1OG6oUG015565 for ; Thu, 24 Feb 2011 09:06:50 -0700 Received: from d03nm128.boulder.ibm.com (d03nm128.boulder.ibm.com [9.17.195.32]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p1OG6oeH015560; Thu, 24 Feb 2011 09:06:50 -0700 In-Reply-To: <56CC7223-9083-4D01-8968-99875782480B@ryandesign.com> References: <4D653858.7070403@gmail.com> <4D65B8FE.8090908@acm.org> <56CC7223-9083-4D01-8968-99875782480B@ryandesign.com> Subject: Re: ^M Appends to every line? X-KeepSent: 6098ECBF:FFED73BC-87257841:0057D00C; type=4; name=$KeepSent To: Ryan Schmidt Cc: users@subversion.apache.org X-Mailer: Lotus Notes Build V852_M2_03302010 March 30, 2010 Message-ID: From: Christopher D Haakinson Date: Thu, 24 Feb 2011 11:02:04 -0500 X-MIMETrack: Serialize by Router on D03NM128/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 02/24/2011 09:02:10 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C" --0__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C Content-type: multipart/alternative; Boundary="1__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C" --1__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable OK, so I've been testing out the svn:eol-style prop and it appears to w= ork, but it seems like an awful lot of work for such a simple issue. Is there something server-side I can setup to ensure that all files con= tain the correct eol style? Also I've noticed that my shell scripts are now failing with an EOF err= or? Does this mean that there's a style setting for the end of file too?? |------------> | From: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |Ryan Schmidt = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |------------> | To: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |David Chapman = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |------------> | Cc: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |Nico Kadel-Garcia , users@subversion.apache.org = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |------------> | Date: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |02/23/2011 09:04 PM = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |------------> | Subject: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| |Re: ^M Appends to every line? = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -----| 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 file= s 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 wh= en >> 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 y= ou 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 (would= n't work as designed) if you check out a working copy on a platform with on= e 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 speci= fic eol style instead -- for example LF. Then you would have to configure a= ll 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 comm= it, your Subversion client would notice the change and convert it back to j= ust 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 bro= ken in this way, unless you remembered to change a particular preference setting. NOT using svn:eol-style at all will remove all eol checks that Subversi= on 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. = --1__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

OK, so I've been testing out the svn:eol-style prop and it appears t= o work, but it seems like an awful lot of work for such a simple issue.=

Is there something server-side I can setup to ensure that all files con= tain the correct eol style?


Also I've noticed that my shell scripts are now failing with an EOF err= or? Does this mean that there's a style setting for the end of file too= ??



3D"InactiveRyan Schmidt ---02/23/2011 09:04:= 30 PM---On Feb 23, 2011, at 19:48, David Chapman wrote:

=
3D=
From:		= 3D""
Ryan Schmidt <subversion-2011a@ryandesign.com>
3D=
To:
David Chapman <dcchapman@acm.org>
3D=
Cc:		3D""
Nico Kadel-Garcia <nkadel@gmail.com>, users@subv= ersion.apache.org
3D=
Date:		= 3D""
02/23/2011 09:04 PM
3D=
Subject:		3D""
Re: ^M Appends to every line?




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 cli= ent 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 enviro= nment,
>> and you are tweaking files back and forth in end-of-line setti= ngs 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 con= fusion
>> 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 Wi= ndows,
>> there are other tools, including the same tools under CygWin.<= br> >
> Uh, no.  Use of "svn:eol-style" avoids a world of h= urt - programmers do not have to run a script *every* time they check o= ut 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 ki= nd of local rewriting you want to avoid.


Some have the view that setting svn:eol-style to native is a problem; p= erhaps 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 y= ou 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 co= mpletely 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 Subversi= on won't handle for you, and will abort the commit with an error messag= e, is if your editor decides to save a file with mixed line endings. Su= ch editors are broken IMHO. UltraEdit is an example of an editor we use= d which was broken in this way, unless you remembered to change a parti= cular preference setting.

NOT using svn:eol-style at all will remove all eol checks that Subversi= on does, and if you are using multiple editors on multiple platforms, y= ou will most probably end up with files of mixed line ending styles. TH= AT is a recipe for disaster.




= --1__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C-- --0__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=08BBF2D2DFC4569C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=08BBF2D2DFC4569C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=08BBF2D2DFC4569C8f9e8a93df938690918c08BBF2D2DFC4569C--