[Python-Dev] PEP 385: the eol-type issue

[Dirkjan Ochtman]

On Wed, Aug 5, 2009 at 01:43, Mark Hammond<mhammond at skippinet.com.au> wrote:
> Thanks Nick; I didn't want to be the only one saying that.  There is a fine
> line between asserting reasonable requirements for Windows users and being
> obstructionist and unhelpful, and I'm trying to stay on the former side :)

I'm not trying to be obstructionist and unhelpful (I hope that should
be obvious). On the other hand, I'm working from the point of view of
hg, which has two assumptions:

- we're a distributed system, there's fairly little we can assume about clients
- we exchange checksummed byte streams (even if we have some tools
that assume those streams are code)
- because of the previous point, there's one native (and therefore
better, in a sense) serialization of what you consider "structured"
data

The first point means, for example, there will always be some clients
who don't have win32text enabled, no matter what, so you can't rely on
it, which is why I want to make the server hooks the primary line of
defense, and view the client-side tools as helper tools (to make it
easy not to trigger the server-side hooks). That doesn't mean I think
Windows users are second-rate, or anything like that!

> I'm not that happy with the server being the primary line of defense. Let's
> say I make a branch of the hg repo, myself and a few others work on it
> committing as we go, then attempt to merge back upstream.  Let's say some of
> the early commits on that clone introduced "bad" line endings.  I'm guessing
> I would be forced to make a number of whitespace-only checkins to normalize
> the line-endings before it could merge - and these checkins would then be in
> the history forever.  Or I could attempt to recreate the clone by somehow
> "replaying" the commits with line endings corrected.  Either way, the
> situation doesn't seem good.

I don't think either is bad. In the first case, you have one or maybe
two extra changesets. As we like to advocate small changesets that fix
one thing, a changeset fixing up whitespace is par for the course. ;)
The other solution would be to employ mq, for example, to fix up the
commits, which mq excels at (although admittedly it has a learning
curve).

> I agree.  It isn't fair to make this windows users problem.  It would be
> like me proposing the repo get imported with \r\n line endings, enforce that
> with server side hooks, and let non-Windows users worry about the
> ramifications of that - somehow I doubt that would fly - so neither should
> it fly for Windows users...
>
> I'm more than willing to help on this; I haven't resurrected my stale patch
> because I find win32text only 1/2 a solution that doesn't work in practice.
>  Therefore that patch is as stale for me as it is anyone. However, if a plan
> is put in place which offers a full solution and the hg developers are
> committed to it, I promise I'll put my hand up to help with implementation
> in a fairly timely manner...

Well, I'd be happy to help convince the hg crew to accept whatever we
come up with, but I'm not sure I'm the best person to come up with it.
It sounds like a versioned .hgeols would help a bunch of issues, but I
have the feeling you know that better than me, so I'm hoping you can
come up with a concrete proposal on what should change in win32text to
fix all the problems you see.

Cheers,

Dirkjan