--- Jeff Smith wrote:
> On Friday 02 February 2007 10:30, Frodak wrote:
> > 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.
>
> In all cases I know, the answer was 3.
>
> You are thinking too abstract, and it only limits
> your productivity in
> the real world.
>
> 1. Reading from left to right has always worked for
> me (anyone else?)
> 2. It has not hurt yet to be wrong on that rare case
>
> Explanation of 1.
> If you read left to right, being greedy (consuming
> two-byte EOL if
> possible), you will get the most accurate conversion
> in practice.
> That failing, look at 2.
But that is heuristic you are applying to EOLs that
can be wrong based upon your assumption that EOLs are
2 bytes or 1 byte. You have no way of knowing how
many blank lines there were. How do you expect SVN to
track the number of blank lines if nobody knows.
> Explanation of 2.
> For everyone suggesting that I "simply" spend an
> extra half-hour using
> yet another tool to convert these special cases when
> svn already was
> converting all the text files for me, what is your
> point? The other
> tool made the same mistakes you were afraid that svn
> might make, and
> it DID NOT MATTER. As we keep saying, with text
> files, important
> thing is to not lose EOL (don't join two lines that
> were meant to be
> seperated). OTOH losing or adding a _blank_ line on
> some rare
> occasion has not been a problem whether it was svn
> or dos2unix.
But it can be wrong. Just because a missing _blank_
line doesn't matter to you, doesn't mean it doesn't
matter to others.
> I am only talking about import/add. If you are
> talking about checking
> in a file, you checked it out with
> svn:eol-style=whatever, and your
> editor *still* corrupted the file, I think svn
> should at least
> require a --force, or tell the user to get
> themselves a REAL EDITOR
> first!
>
> Have you ever noticed a C file has somehow inserted
> an extra blank
> line or left one out? I never did until now. It was
> doing it all
> along, I just didn't notice. That's how
> insignificant it is in most
> text files.
Not all text is a c file. It is quite presumptuous of
you to dictate what is insignificant.
> Shoot the whole problem that I'm trying to solve is
> that I'm trying to
> track changes in text files, and svn is trying to
> stop me from doing
> that. I've already TOLD subversion in config which
> files are text
> (*.c, *.h), and which eol-style to use. I'm not
> wanting it to do it
> without my knowledge. What the heck kind of goal is
> that for svn?
> Stop my productivity? If I just import everything as
> binary, then I
> cannot track changes because it shows me EVERY line
> is changed when I
> only changed one (sorry I can't tell you which one).
>
Sigh, SVN isn't stopping you. The client-side config
settings don't effect how the repository is tracking
the file. You have to set the file properties when
importing or adding the file.
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 2 21:35:36 2007