The only way to really fix it, is if everyone remembers to update their
svn config.... We *ask* everyone to do so on Geronimo and as we find
problems (like missing svn props) we'll fix them and remind the
committer to update their config, but no one scans the source before
every release to fix them.
I have seen issues before on Linux with Windows files, but so far my Mac
tools have been able to handle them, so this is not an urgent fix by any
means.
-Donald
Kevin Sutter wrote:
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 <[email protected]>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) <[email protected]>
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.
