> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Tuesday, January 30, 2007 5:55 AM
> To: Mark Moore
> Subject: Re: What do you Hate about Subversion?
>
> Mark Moore wrote:
>
> > There's no standard for good robust coding, although self respect can be
> a
> > strong motivation. The line ending problem has been around for going o
> 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)
> 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.
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.
> There are on-the-wire standards for the
> intermediate form during transfers using certain protocols,
Agreed.
> 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".
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.)
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.
Where the "on-the-wire" standard for SVN *can* apply in this case is
enforcing this by disallowing any transformation on EOL at all.
> > 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)
> > The only tough problem is what to insert if you find yourself needing to
> add
> > an (additional) EOL. A perfectly reasonable approach would be to insert
> a
> > copy of the same EOL sequence you've previously found. If there are no
> > other EOL's in the byte stream, and you still need to insert an EOL
> token,
> > then pick your personal favorite since all the other (robust) (modern)
> text
> > processing tools will handle it just fine.
>
> It is fine to imagine a perfect world, but remember that there are
> probably more copies of notepad around than anything else. From
> subversion's perspective, the question is: is a line changed if only the
> line ending style changed on a text file?
Yep. Again, Subversion can make *no* assumptions about how a source file
has been used on a particular platform. Changes are changes.
> And does it matter if the
> change was to/from the native version for the platform running the svn
> client or should it permit any style to be equivalent?
Any EOL style should be equivalent, and SVN should not care what generated
the change.
To be clear in closing, (and IMHO,) both the Subversion client and server
should strive to minimize their dependencies on end-of-line as much as
possible.
Where it's not possible to eliminate an EOL dependency, the Subversion
system should accept any form of EOL in a platform agnostic manner. (See
above for existing examples.)
I believe Subversion could be modified to *never* need to inject new (or
additional) EOL's, but if this is not possible (or too difficult), it should
insert the same form as the last EOL detected. But to be honest, (almost)
any form of EOL is fine.
> --
> Les Mikesell
> lesmikesell@gmail.com
BTW, I'm sure you're already aware, but our last two emails have been
off-list since my response was more for you than SVN in general. This one
I've CC'd to the list since it contains Subversion reccos. -MM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 30 16:40:14 2007