Thank you for your long answer ... but I had intended my question as
mostly rhetorical. :-)
On 2/2/07, Jeff Smith <jsmith@robotronics.com> wrote:
> On Friday 02 February 2007 09:30, Hilco Wijbenga wrote:
> > TEXT\r\n
> > or
> > TEXT\r
> > \n
> ^^^^^ I see you are inherent DOS user, assuming "\r\n" means
> line-end
No, I'm on Linux. I'm not assuming anything ... I'm trying to point
out that it is (in general) impossible to determine how many lines
(i.e. EOLs) a "text" file contains if mixed EOL indicators are being
used.
> 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?
Knowing that it's a text file doesn't make a real difference. Given
that multiple interpretations exist as soon as multiple EOL indicators
are present, there is no 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.
Yes, I'm sure that in certain cases it may be possible to determine
the most likely intent but we're talking about a revision control
system. So "most likely" and "in certain cases" is not good enough.
Not to mention that we don't want Subversion to make changes to a file
when importing/committing it.
> 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!
Unintentional mixed EOL (*intentional* mixed EOL would indicate a
binary file, I think) means user error. The user is sending ambiguous
signals: he says the file is text but then doesn't follow the rules
relating to EOL. I think Subversion should refuse to import/commit
such files.
Cheers,
Hilco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 2 22:19:47 2007