openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Ezzio <dez...@apache.org>
Subject Re: Line endings
Date Fri, 08 Feb 2008 16:29:58 GMT
Hi Patrick,

I'm not sure who the notepad users are.  Certainly, not me.  I'm not 
sure where notepad is on my Windows machine.

We do have a choice.  We can leave things as they are and not get too 
upset when developers inadvertently mess things up by accidentally 
changing the line ending style on their client copy when checking in a 
changed file.

Or, we can regiment the files to native, making it much more unlikely 
that developers will inadvertently change the line endings.

We do know that all as-is files with UNIX (or was it DOS?) line endings 
can have their eol-style attribute changed without recording a change in 
every line.  One of the files in my experiment yesterday did just that. 
  So that change alone applied across the code base might reduce the 
problem children by half, from 40% of the files to 20%.

It is also possible that we can hack the other 20% by some tricky moves 
that we can discover through some more experiments.  Finally, maybe 
there are some scripts that can be run on the repository that would 
effect the change without messing with the history.

David


Patrick Linskey wrote:
>> 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 <dezzio@apache.org> wrote:
>> Hi,
>>
>> Based on an experiment, it looks like the regimentation of existing
>> files to native will be easy to perform.
>>
>> In r619411, I changed two files from as-is to native.  One was present
>> 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
>> 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.
>>
>> I propose that I find an hour or two next week and regiment all files
>> with a non-native setting to the native setting (about 60% of the code
>> base).
>>
>> David
>>
>>
>> David Jencks wrote:
>>> 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
>>>
>>> I think there are scripts to help normalize stuff that has strayed from
>>> 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:
>>>
>>>> Hi David,
>>>>
>>>> Thanks for volunteering to do this.
>>>>
>>>> I recall we discussed whether to use LF or native. But I don't recall
>>>> 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:
>>>>
>>>>> Hi,
>>>>>
>>>>> 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
>>>>> settings: CR (Mac), LF (Unix), CRLF (DOS), native (convert to/from
>>>>> client platform) or as-is (no conversion, no regimentation).
>>>>>
>>>>> 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
>>>>> 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
>>>>> all of the files to one agreed upon format, anytime that we'd care to
>>>>> do so.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> David
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>
> 
> 
> 

Mime
View raw message