Line ending translation extension

["Martin v. Löwis"]

> I suspect you haven't experienced any
> problems at all with *Mercurial*, except in quick tests which you
> admit need to be reevaluated.  

That's more or less correct.

> Ditto Mark Hammond.

I don't think that's the case. I believe he mentioned at one point
that he committed files incorrectly into a large repository (IIRC,
it was Mozilla). So there is more than shallow experience here.

> 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.

I don't see how this has anything to do with the decentralized behavior.
Can you please be more specific?

>  > 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.

No, he can't - because then the extension will become unmaintained.
So the situation would be just like win32ext: it is there, it is
unmaintained, and it doesn't quite work.

>  > > 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..
>  > 
>  > 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.

"it" being your method B - there are no URLs discussing it, since
it isn't implemented yet.

This method (treating project files as binary) can't work since it
allows people to introduce mixed eol styles into the file, which
would break the tools that want to process the files.

> 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.

So start investigating things, and contributing code, to ease that
nervousness.

> 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).

I'd be happy if somebody who you would accept as expert comes up
with a specification (as long as it supports Python source files
to show up in CRLF on disk on Windows).

Notice that the strategy "let's follow svn" is *not* ad-hoc. It
gives a very clear guideline on how this feature should behave.
Whether that will be useful in practice remains to be seen, but
the strong indication is that it has worked well for Subversion,
and did work (in a more limited form) for CVS before.

FWIW, git supports the crlf attribute, which is very similar to
the proposed feature. Bazaar has the *same* feature since 1.14:

http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line-conversion

So I don't buy the argument that DVCSs are different and don't
need the feature.

Regards,
Martin