On Friday 02 February 2007 09:30, Hilco Wijbenga wrote:
> So how is a file with mixed line endings supposed to be interpreted
> then?
>
> ....\r
> TEXT\r\n
> ....\n
> MORE\n\r
>
> Does that mean
>
> TEXT\r\n
> or
> TEXT\r
> \n
^^^^^ I see you are inherent DOS user, assuming "\r\n" means
line-end
Ah, finally a new question to answer. Thanks! Of course I think my
answer is good, but of course someone would insist that in some odd
case it wouldn't work, and I understand that. Working long-term with
DOS and dumb terminals, I can really appreciate your question.
BACKGROUND
In a system where '\r' is a real "carriage return" and '\n' is only a
"new line", people have made use of those in different ways for
contoling the carriage on a screen or printer. On a specific
printer/screen the \r could be used to force writing over the same
line that was just written, whether to strike over or update a
"status" line (on a screen which doesn't keep previous contents). As
far as using "\n" alone, the only purpose I've seen is to mess up the
printer...
This
is
messed
up...
[Which is no purpose at all].
Please note that if you store these deliberate "control" codes into a
file, that makes it NOT a text file.
ORIGIN OF PROBLEM [that we need to solve]
So most people here are aware by now that the above purpose of using
\r and \n independently are NOT the problem we are trying to discuss.
We are only talking about importing text files. Therefore, the ONLY
reason a _text_ file has mixed EOL styles is because it was
_unintentionally_ mixed by editing with multiple tools/environments.
The origin of the problem, then, is that someone has edited a text
file with a different editor which thought '\r' instead of '\r\n' was
sufficient to mark the EOL which it just inserted. Of course there
are possible combinations of this, like another editor uses '\n'
instead, as you show in your example. This may make it more dificult
for an automated tool to detect if it is a text file, but does the
user not know if "main.c" is a text file?
SOLUTION
Given the origin of the problem (another editor inserted a \r for
newline in a file that otherwise used \r\n, then of course we know
what the \r means... it is a newline! Great, we've answered your
question thoroughly :) Could the user be wrong to assume main.c is
a text file? Of course, but the user will be responsible for that,
not svn.
I haven't heard anyone dispute that svn is the tool intended to help
developers develop a single code base from across multiple platforms.
Then it is the right tool to add this feature. Our point is that
handling a text file that has the unintentional mixed EOL should be
handled no differently than all of the other text files having
different style. So ask the user if it is a text file, don't just
abort, we have not gaing anything by aborting!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 2 19:42:09 2007