At 10:26 2007-02-02, Frodak wrote:
>--- 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.
it's 2 blank lines... the first \r\n is at the end of a non-blank line <sigh>
and, IF your perl program "cares" about it, it's BROKEN (the comment
that started this entire thread)
> > 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
Victor A. Wagner Jr. http://rudbek.com
The five most dangerous words in the English language:
"There oughta be a law"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 5 04:32:03 2007