Mark Moore wrote:
>>> The line ending problem has been around for going on 50
>>> years (at least), and the solution has been well known (and captured on
>>> standards) for going on 15.
>> Can you quote the standard?
>
> Yes. Here are three:
>
> 1) PostScript Language Reference, 3rd Edition (ISBN 0-201-37922-8)
> See "End-of-Line Conventions in Section 3.8.1 Basic File Operations.
> Here's a link to an online version:
> http://www-cdf.fnal.gov/offline/PostScript/PLRM2.pdf
> See page 73. (Incidentally, the 1st edition was published in
> 1986, so I was wrong. This technique has been captured in at
> Least one standard for over 20 years.
>
> 2) Python Reference Manual
> See section 2.1.2 Physical lines
> (http://docs.python.org/ref/physical.html)
>
> 3) The Java Language Specification
> See section 3.4 Line Terminators
> (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#231571)
Those aren't standards, those are 3 special cases, each only applicable
to one language, and then not even to non-integral tools that are likely
to manipulate the text. The fact that each of these special cases had
to be specified should point out that there is a general problem that
isn't solved in the general case and isn't likely to be anytime soon.
>> I have never seen anything from a standards
>> body that felt it was within the scope of their duty to tell any
>> operating platform what their line ending character should be. Or how
>> to deal with any other.
>
> I humbly think this is where your confusion stems from. These standards
> cover their respective (and bounded) domains. They don't presume to tell
> the operating platform what it can and cannot do. Instead, these standards
> define what their conformant implementations MUST do.
There is no confusion. Until _every_ possible operation on text files
has such a standard for 'conformant implementations' and all code is
changed to comply, transformations are going to be required for cross
platform tools.
> To bring this back to Subversion, by analogy, the SVN standard could (and I
> strongly believe it *should*) define that conformant clients and servers
> should accept end-of-line tokens in a platform agnostic manner similar to
> the way the few select examples you asked for above have already
> demonstrated.
>
> As an aside, I recognize there is no Subversion "standard" per se, but
> please recognize that the SVN source code forms a standard since conformant
> clients and servers are based on it.
>
> I believe the source should be modified to accept CR, LF, or CR-LF as end of
> line tokens interchangeably. This would remove the need to modify EOL in
> text based sources as they were being stored in the repository, or being
> sent over the wire.
It would eliminate the need within svn. It would not provide the
capability to deliver usable 'text' to any particular platform. However
that capability already exists for the typical case where you want the
native style for the client where you execute the commands. We've seen
cases described here where that isn't true.
>> but that
>> can't apply to the cases where the protocol transfers to one platform
>> but the data is intended for use on another.
>
> I don't agree. It depends on what you mean by "intended for use".
Precisely, which is why you need a way to describe it.
> Subversion should make no assumptions about how a text or binary image will
> be used or has been used on a target platform. It simply has no way of
> knowing. (I hope this is self evident.)
It already does have a way of knowing in the case where you want native
text handling. It should not be particularly difficult to give the
popular styles their own names and request that instead of native for
the checkout platform.
> Because it has *no way* of knowing how a source file will be used once it's
> checked out of SVN, both the client and the server should make *no*
> assumptions. Specifically, they shouldn't change the end-of-line token.
Of course it knows the difference between binary and text files, and it
must change end-of-line on text. Anything that handles text across
platforms must do that.
> Where the "on-the-wire" standard for SVN *can* apply in this case is
> enforcing this by disallowing any transformation on EOL at all.
There is already that option as well. It isn't pretty.
>>> It's just pathetic that text processing tools can't reliably find the
>> EOL
>>> regardless of the byte stream's origination. And, having found the EOL,
>>> it's pathetic if it tries to change it.
>> Agreed, but history is history, and a revision control project should
>> recognize that you can't change it.
>
> Agreed. You can't change history, and you can't (or shouldn't) change EOL.
> ;o)
Unless you want to use the text portably... That much should be clear
from the examples given already.
> Yep. Again, Subversion can make *no* assumptions about how a source file
> has been used on a particular platform. Changes are changes.
Assumptions are bad. Doing what the user requests is good.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 30 18:29:19 2007