Re: Is it time to fix the svn:eol-style properties?

[Craig L Russell]

Hi Donald,

On Feb 24, 2009, at 11:44 AM, Donald Woods wrote:

Reviving this thread, as I'm also finding source files, like -

openjpa-persistence/src/main/java/org/apache/openjpa/persistence/ EntityManagerImpl.java that are using the Windows EOL chars, which causes patches generated by "svn diff" on Linux/Mac to replace the content of the whole file to fix the EOL chars... Still don't see why there is such a concern about SVN commit noise or that it adds one svn log entry per file. The benefits outweigh the svn commit email and log history addition.

Thanks,

Craig

I'm not parsing this paragraph correctly, as it sounds self- contradictory. Could you review and make sure it's what you mean? My position is that we should adopt a uniform line end policy and change all of the svn line endings properties in the project separate from any code changes. Is this also what you are proposing?

-Donald


Craig L Russell wrote:

There are perl scripts floating around to recursively fix source branches (can't find one right now), or you can do it for every subdir - svn propset svn:eol-style native -R openjpa-persistence/src/main/ java/org/apache/openjpa/persistence/*.java

I'd agree to these changes if the svn eol property were checked in at the same time. That solves the long term problem. See http://svnbook.red-bean.com/en/1.1/ch07s02.html for details on svn:eol-style. For the project, we need to decide which eol style to use. Both/ either LF and native work fine for most people.

Craig
On Feb 4, 2009, at 1:44 PM, Kevin Sutter wrote:

Mike,

incorrect EOL characters stay out once they are removed?

Kevin

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 On Wed, Feb 4, 2009 at 3:02 PM, Michael Dick <michael.d.d...@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.


precedent against cleaning up eol chars.

Any agreement / dissent to committing the patch?

-mike


wrote:

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 On Wed, Feb 4, 2009 at 1:01 PM, Donald Woods (JIRA) <j...@apache.org >

  [

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.

command -
{noformat}
#! /bin/sh
for x
do
echo "Converting $x"
tr -d '\015' < "$x" > "$x.tmp"
mv "$x.tmp" "$x"
done
{noformat}

For Mac users, you need to provide a dos2unix script that uses the tr

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.

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@sun.com
P.S. A good JDO? O, Gasp!

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@sun.com
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature