[Python-Dev] Mercurial migration: help needed

"Martin v. Löwis" martin at v.loewis.de
Sat Sep 5 15:19:43 CEST 2009

> I'm starting to wonder what the problem really is that makes it so
> Python-specific. If I understood correctly, it's about a couple of files which
> must be stored using non-Unix line endings, right? (in the PC and PCbuild
> directories?)

No. It's about files that must, when checked out on Windows, have CRLF
endings, and, when checked out on Unix, have LF endings - i.e. all the
.py, .c, .h, and .rst files, plus a couple of others which don't require
specific treatment.

IOW, it's about the default behavior, and the majority of new files.

> These files are hardly modified often and by many people (and even more rarely
> by non-Windows people), so why not just put a verification hook on the server
> and let the offending committer repair his mistake manually, if it ever happens?
> (we can even provide a script to help repairing the EOL mistake, like
> Tools/reindent.py does for indentation mistakes)

This was Dirkjan's original proposal, and it is the proposal that brings
so much heat into the discussion, claiming that it is a problem of
minorities (I do understand that you were unaware that "the problem"
is really with the many files, not with the few).

In addition, a DVCS brings in another problem dimension: when people
push their changes, they have *already* committed them - and perhaps not
even they, but a contributor from which they had been pulling changes.
The bogus change may have been weeks ago, so the subversion solution
(of rejecting the commit to happen) doesn't quite work that well for


More information about the Python-Dev mailing list