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

[Mark Hammond]

On 5/08/2009 6:25 PM, Dirkjan Ochtman wrote:
> 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).

It is, and I hope I didn't imply otherwise.

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

In general I agree - although I think we can enforce a "social contract" 
which puts requirements on people who commit to the Python repository - 
and therefore we can consider the server-side hooks a "secondary" 
defense.  IOW, the system (including the social aspects of the system) 
are setup such that the server-side hooks are very rarely called upon.

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

With all due respect, I suspect that is because you don't expect to see 
the issue regularly.  This proposal still leaves the problem squarely in 
the lap of Windows users and imposes a burden on them that would 
probably be considered unreasonable if the situation was reversed.

I'm yet to work on a hg repository without mixed line endings.  If I 
understand correctly, every such repository would have involved a 
developer checking in locally, than at some point in the future pushing 
these changes upstream.  I really really don't want hg to tell me at 
this final step that I need to perform whitespace only fixes purely 
because I am running Windows.

I understand we are discussing how win32text can offer that - but I must 
object to your assertion that the situation I described isn't bad when 
you hit it.

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

Actually, I think it is easy to make this problem much easier to 
understand; mandate every platform should use win32text, then start 
collating the issues people, including yourself, will no doubt face. 
I'm happy to get this ball rolling, but again, don't want this left 
purely in the domain of "it is a windows problem" - it isn't.

Cheers,

Mark