Line ending translation extension

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > It's a problem for Python.

OK.  But it directly affects only Windows users, and it's
disheartening to hear *all* Windows users disclaim intention to take
any responsibility for the problem, which is occasioned by a change
intended to benefit *all* Python developers, several of whom have
acknowledged responsibility for the Windows issues in varying degrees
(ranging from merely posting to this thread to Brett's concession of
veto over the whole migration based on this issue).

 > > What I see asserted is quite different: that (a) they don't experience
 > > it themselves, and (b) that they don't understand how a problem can
 > > arise frequently enough to worry about it.  Some of those people
 > > develop primarily for and with Windows!
 > 
 > However, it's puzzling that people repeat these assertions, despite
 > having seen explanations for why it happens.

Knowing that there are reasons why something does happen, and
believing that it happens frequently enough to be worth blocking
something as big as the DVCS conversion, are two different things.
I'd like to see URLs for threads where the problems are discussed by
people who have actually experienced problems.  You yourself use the
word "fear" multiple times.  I suspect you haven't experienced any
problems at all with *Mercurial*, except in quick tests which you
admit need to be reevaluated.  Ditto Mark Hammond.

Yes, your past experience with CVS and Subversion is relevant, but
that was years ago; the environment has changed.  It's quite possible
that the situation where "all Windows committers committed CRLF files
inappropriately" in 2005 is now changed to "25% of committers use
tools that put them at risk of this issue."

And the design very likely has to change, to deal with the
decentralized, content-oriented behavior of DVCSes.  It seems to me
that your question about hg diff acknowledges that the proposed design
is incomplete in this sense.

 > > This is important to the design.  AIUI, Martin v. Löwis is saying
 > > "right, it's pretty rare, but *extremely* annoying when it does
 > > happen
 > 
 > No - I don't think I said it's pretty rare

Conceded.  I was probably projecting my own experience with XEmacs,
which is a special case.

 > What he is concerned about is that he may have to maintain the
 > extension if he just barely touches it. I can understand that.
 > The hard problem is a social one, not a technical.

Indeed it's social, but it's not about maintaining the extension.  For
that, he can "just say no" at any time.

 > The technical problem primarily comes from ad-hoc solutions, such
 > as win32text. This tries to eliminate the need for configuration,
 > by applying magic [...]
 > 
 > > Method A: Text files are labeled according to target platform
 > > convention: LF, CRLF, or native.  LF and CRLF are checked out as
 > > binary, checked for the proper conventions on check in, and converted
 > > as necessary.  This would give some additional flexibility, and better
 > > checking, but it's more complex.  Visual Studio project files would be
 > > labeled as *CRLF*.  This seems the leading candidate.
 > > 
 > > Method B: Text files are always decoded and reencoded according to
 > > user preference, defaulting to platform convention.  Visual Studio
 > > project files would be classed as *binary*.  This is simpler and
 > > flexible but allows less fine-grained checks..
 > 
 > In this method, how do you know what a text file is?

My description was incomplete.  In all methods, there needs to be a file
property managed by hg.  What values of that property are, and their
detailed semantics varies across methods.

 > I think this is a description of win32text,

I disagree.

 > and it doesn't work.

I can't see how it could if it "guesses" and isn't maintained.  Such
guessing needs to be tweaked continuously to approximate accuracy.

Still, I'd like to see URLs to descriptions of *exactly* how it fails
to work in practical situations.  I get very nervous when you say on
the one hand "we have a proposed solution that seems close if it
works," and on the other "I don't even know how hg diff works."  That
sounds very ad hoc to me.

Not to mention that the people who are actually working on the
solution are doing ad hoc fixups based on random comments in this
thread, rather than a specification from somebody who knows what he's
trying to do (in a concrete, in-the-context-of-Mercurial, way, not in
a "let's avoid the mistakes we made with Subversion" way).