Hi Craig,
Ah, if it could only be as easy as you suggest!
If I understood what actually happened in my experiment, it was this.
Existing as-is files are stored in the svn repository just as they come
from the client. Likewise, they are checked out onto the client just as
they are in the repository.
Changing a file with UNIX line endings and as-is eol-style (on any
client) to native will change the eol-style, and not make any changes in
the repository, as UNIX eol-style is the internal format of the
repository (I'm guessing.)
Changing a file with DOS line endings and as-is eol-style (on any
client?) to native will change the eol-style and change the internal
image in the repository to UNIX style, resulting in a change for every
line of the file.
So the results that I believe I observed were the opposite of what you
hypothesized. It was the UNIX line ending file that recorded only the
eol-style change, and the DOS line ending file that recorded a change
for every line, when the change of eol-style was performed from a DOS
machine.
Someone could rerun the experiment on two files and see if they observe
the same thing, and also try it on a UNIX box to see if there is
different behavior.
David
Craig L Russell wrote:
We can probably not lose history when converting if we examine all the
as-is files and make the change on the appropriate machine.
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.
Craig
On Feb 7, 2008, at 8:01 AM, 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 <[EMAIL PROTECTED]> 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:[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!
