--- Les Mikesell <lesmikesell@gmail.com> wrote:
> Duncan Murdoch wrote:
> >>
> >> Given the possible combinations, it is not at all
> difficult.
> >> Generally you'd want \r, \n, \r\n, and an oddball
> \n\r to be
> >> equivalent on the way in,
> >
> > Okay, suppose we're on Windows, where the native
> format says \r\n is an
> > eol. Treating \r, \n, \r\n to be "equivalent on
> the way in" means they
> > all get transformed to \n in the repository, the
> way \r\n is currently
> > handled? Then as soon as I checked them out
> again, they'd all be
> > converted to \r\n. That was my first option:
> convert everything to
> > text. But here you've got a version control
> system modifying your
> > files. I don't think that's something it should
> do. Changing files is
> > the responsibility of the user. svn should not
> change files, except in
> > perfectly reversible ways (the way it currently
> handles true text files).
>
> I think we have a philosophical difference about the
> nature of text.
> Text existed long before computers with their
> various ways of
> representing it, and representing it in different
> ways does not change
> the content of the text. If you want to store it in
> ascii or ebcdic it
> is the same content. If you want to put it on punch
Not true. It is well known that character encodings
are not always 1 to 1. Compare ASCII to latin-1 they
are both "text".
> cards that don't
> have a representation for line endings, it's still
> the same text. And
> it certainly doesn't change just because different
> currently popular
> platforms represent the line endings in a slightly
> different way. The
> important thing for a revision control system
> handling text is that it
> can show the differences in content, not the
> unrelated storage format
> that may have held it at various times. Suppose you
> wanted to present
> the text of a proposed amendment to a law for a vote
> in some political
> body. Would you show just the changed wording in
> its context, or would
> you have to present the entire volume in the
> before/after states because
> you had to copy to different media and now can't
> track the portion that
> may be changed?
So how many EOLs are their in "\r\n\r\n\n" is that 3,
4, or 5 blank lines in my text file. Because it does
matter to the formatting of the file. Just because a
c compiler doesn't care, doesn't mean that it is not
important to my perl POD output.
> Subversion has the option of treating files as a
> meaningless stream of
> bytes, which is fine for other purposes. For text,
> it needs to track
> the meaning instead.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
And it absolutely does. I have a file as
svn:eol-style native. If I check out the file and
force it to have mixed EOLs, it will NOT notice at
all.
There is 1 place where I think SVN fails. And that is
when taking an existing file that has svn:eol-style
native or LF and changing it CRLF. This is where SVN
needs to be looked at. Not playing guessing games
about how many EOLs there are in a file when you add
it to the repository the first time.
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 2 18:26:52 2007