Архив — January 10, 2010

Where the Hg transition stands / Brett Cannon

[edit 2010-01-09: links to mailing list archives containing latest discussion]

At PyCon 2009 it was announced that python-dev planned to move Python development from svn to hg. Well, just because we chose our distributed version control system (DVCS) does not mean that we were ready to hit the switch. For one I took a three month sabbatical from python-dev to get my PhD thesis proposal finished (which I did, thank science). Luckily Dirkjan Ochtman stepped in with PEP 385 and volunteered to handle the transition. At that point we thought that it would be a matter of creating a new sys.mercurial attribute (which we still need to code up), write up new developer docs on the workflow we expect to use, and then do a high fidelity conversion of the revision history to hg and then flip the switch.

But then bloody line endings wielded their ugly heads. While I was writing PEP 374 and evaluating the three leading DVCSs I was under the impression that the win32text extension for hg did what we needed. No one every spoke up saying otherwise while the PEP was out for discussion or anything so I simply didn't worry about it

Read full entry at origin

DVCS Ponies / Armin Ronacher

So, I have a pony to share. Just maybe someone likes the idea and has thought of something similar :) So, one of the problems the Python guys currently have with mercurial is, that they need newline normalization/conversion on checkout. The problem with decentralized systems is that the client is a server and runs a stock DVCS client with his own set of hooks. In subversion you have a centralized hook that will check stuff and reject commits or rewrite them if they do not work out as expected.

Now I am very happy that hg is decentralized, but at the end of the day everything ends up in a centralized repository and there certain rules apply. So what I do is review all patches by hand in detail and rewrite parts if they do not match the code style, line endings etc. So what I thought about is doing the check/conversion in a local commit hook and in a pre-changeset hook on the server as well, so that I for myself get stopped early checking stupid stuff in and the server later rejects changesets for sure that are improper.

So I have no problem doing that check twice, but other users that are not so fortunate to have my extension might still check improper stuff in and will not even know it, because nothing stops them from doing so. But I will still have to deal with that later and there will be rejections from the server.

Read full entry at origin