Re: Line endings

[Craig L Russell]

We can probably not lose history when converting if we examine all the as-is files and make the change on the appropriate machine.

Craig

On Feb 7, 2008, at 8:01 AM, Patrick Linskey wrote:

If they have DOS line endings, set the eol-style property to native on a DOS machine. No changes. If they have UNIX line endings, set the eol-style property to native on a UNIX machine. No changes.

On the downside, the file that was in DOS line endings was converted on the server and recorded in the change notice as the entire file changing.

I really don't like the idea of losing all this easy history. Is this
line-ending stuff really a problem? Don't most modern text editors
support multiple line endings?

It seems a waste to lose all that data just to make things easier for
Notepad users....

-Patrick

On Feb 7, 2008 6:09 AM, David Ezzio <[EMAIL PROTECTED]> wrote:

Hi,

Based on an experiment, it looks like the regimentation of existing
files to native will be easy to perform.


on my client with Unix line endings and one was present with DOS line
endings.  I changed the eol property for both files to native and




I propose that I find an hour or two next week and regiment all files

base).

David


David Jencks wrote:

In r619411, I changed two files from as-is to native. One was present committed. When updated from the server, they both came down with DOS line endings, the appropriate native translation for my Windows machine. On the downside, the file that was in DOS line endings was converted on the server and recorded in the change notice as the entire file changing. with a non-native setting to the native setting (about 60% of the code

I think infra strongly suggest everyone uses these svn client settings

to avoid most of this kind of problem:

http://www.apache.org/dev/svn-eol-style.txt


these recommendations but I'm not sure where they are.

thanks
david jencks

On Feb 6, 2008, at 9:09 AM, Craig L Russell wrote:

I think there are scripts to help normalize stuff that has strayed from

Hi David,

Thanks for volunteering to do this.


the outcome.

The reason to use LF is for Windows users who use unix tools. The
reason to use native is for Windows users who use native tools
(Notepad). I personally don't care, except that my svn preferences
file is set up to use LF for new files (for another project).

Craig

On Feb 6, 2008, at 8:41 AM, David Ezzio wrote:

I recall we discussed whether to use LF or native. But I don't recall

Hi,


settings: CR (Mac), LF (Unix), CRLF (DOS), native (convert to/from
client platform) or as-is (no conversion, no regimentation).




as SVN will take care to convert to and from the client's platform
preference upon update and commit.

I believe it would be a relatively simple matter for me to convert

do so.

Thoughts?

David

As I understand it, files within the SVN repository are either text or binary, and if text, they have as a property one of the five SVN Currently, the OpenJPA repository has text files for three of these settings. Most are as-is, a few are LF, and the remainder are native. As I understand it, native is the preferred attribute for text files all of the files to one agreed upon format, anytime that we'd care to

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

--
Patrick Linskey
202 669 5907

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature