On 5/08/2009 6:25 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 01:43, Mark Hammond<mhamm...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
