Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (nike.apache.org: domain of kwsutter@gmail.com designates
 74.125.46.31 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=qy0oeg5dA2+Ltnv3jeMgHOUQxGHmIHFhLuYjWbOKHARIWviaiKEHBNYdkElILrhVuv
         /MN87ArGZEcGO3Gx9OqGC43skLxt9loZMavdC7X3wu+mWFW29b2Tt2EhvNVuAUCgprev
         XGdCKC7i43Z4F78rV1Fak/h6nU5Xj2J9qgzBk=
MIME-Version: 1.0
In-Reply-To: <72c1350f0902041302j52a4f02dgf4bf4b48daae275c@mail.gmail.com>
References: <104861739.1233765599720.JavaMail.jira@brutus>
	 <1820711210.1233774119672.JavaMail.jira@brutus>
	 <72c1350f0902041302j52a4f02dgf4bf4b48daae275c@mail.gmail.com>
Date: Wed, 4 Feb 2009 15:44:23 -0600
Message-ID: <89c0c52c0902041344g7d674f16r165350ef3760881a@mail.gmail.com>
Subject: Re: [jira] Updated: (OPENJPA-896) Several doc files include Windows
	EoL chars
From: Kevin Sutter <kwsutter@gmail.com>
To: dev@openjpa.apache.org
Content-Type: multipart/alternative; boundary=000e0cd32c24e321c304621eb0bb

--000e0cd32c24e321c304621eb0bb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Mike,
I remember those conversations...  :-)  What's the advantage of making or
not making these changes?  This is a huge change.  And, other than totally
tilting our doc change history, does it really buy us anything?  I thought
that as the document gets updated, then the sections would be converted
appropriately.  And, even if we do this change, what prevents us from
corrupting it again?  It seems that this is just an on-going situation.  Or,
are there some controls that can be put in place to ensure that these
incorrect EOL characters stay out once they are removed?

Kevin

On Wed, Feb 4, 2009 at 3:02 PM, Michael Dick <michael.d.dick@gmail.com>wrote:

> This issue came up a few years ago while we were in the incubator. At the
> time (if memory serves) we decided not to fix existing code due to the
> noise
> on SVN.
>
> I'm happy to commit the changes Donald has graciously provided if folks
> agree the noise is acceptable, but I'd prefer to make sure since there's
> precedent against cleaning up eol chars.
>
> Any agreement / dissent to committing the patch?
>
> -mike
>
> On Wed, Feb 4, 2009 at 1:01 PM, Donald Woods (JIRA) <jira@apache.org>
> wrote:
>
> >
> >     [
> >
> https://issues.apache.org/jira/browse/OPENJPA-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> >
> > Donald Woods updated OPENJPA-896:
> > ---------------------------------
> >
> >    Attachment: OPENJPA-896-trunk.patch
> >
> > Patch file which removes the Windows Ctrl+M EOL chars.
> > For Windows users, you can use a program like SlickEdit to resave the
> files
> > in Unix format (and fix your svn config.)
> > For Unix/Linux users, use the "dos2unix *.xml" command.
> > For Mac users, you need to provide a dos2unix script that uses the tr
> > command -
> > {noformat}
> > #! /bin/sh
> > for x
> > do
> > echo "Converting $x"
> > tr -d '\015' < "$x" > "$x.tmp"
> > mv "$x.tmp" "$x"
> > done
> > {noformat}
> >
> > > Several doc files include Windows EoL chars
> > > -------------------------------------------
> > >
> > >                 Key: OPENJPA-896
> > >                 URL: https://issues.apache.org/jira/browse/OPENJPA-896
> > >             Project: OpenJPA
> > >          Issue Type: Bug
> > >          Components: docs
> > >            Reporter: Donald Woods
> > >            Priority: Trivial
> > >             Fix For: 2.0.0
> > >
> > >         Attachments: OPENJPA-896-trunk.patch
> > >
> > >
> > > Several of the doc files include the Windows Ctrl+M chars at the end of
> > lines when checked out to non-Windows platforms (like MacOSX and Linux),
> due
> > to the committer not using the ASF suggested svn config values -
> > http://www.apache.org/dev/svn-eol-style.txt
> > > From http://www.apache.org/dev/version-control.html -
> > > Configuring the Subversion client
> > > Committers will need to properly configure their svn client. One
> > particular issue is OS-specific line-endings for text files. When you add
> a
> > new text file, especially when applying patches from Bugzilla, first
> ensure
> > that the line-endings are appropriate for your system, then do ...
> > > svn add test.txt
> > > svn propset svn:eol-style native test.txt
> > > Your svn client can be configured to do that automatically for some
> > common file types. Add the contents of the file
> > http://www.apache.org/dev/svn-eol-style.txt to your ~/.subversion/config
> > file. [Note: for Windows this is normally found at C:\Documents and
> > Settings\{username}\Application Data\Subversion\config]
> > > Some files may need additional properties to be set, for example
> > svn:executable=* should be applied to those script files (e.g. .bat,
> .cgi,
> > .cmd, .sh) that are intended to be executed. Since not all such files are
> > necessarily intended to be executed, the executable property should not
> be
> > made an automatic default.
> > > However, you should still pay attention to the messages from your svn
> > client when you do 'svn commit'.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>

--000e0cd32c24e321c304621eb0bb--