On Tue, Feb 8, 2011 at 10:29 AM, Mark Hammond <mhamm...@skippinet.com.au> wrote: > On 8/02/2011 12:17 PM, Vernon Cole wrote: >> >> My personal stuff is on bzr and I have put my open source stuff on hg, >> partly because you said you were switching to it. A 3rd dvcs is one too >> many IMHO. > > Yeah - back in April 2009 I stated I would move to hg. But given the time > that passed, a few personal experiences and the various discussions on > python-dev about some if the pain it is facing, I was looking if anyone's > experience over the last couple of years could sway me away from it. > Apparently not - which I *think* is good :)
To be fair, I think any VCS would have caused numerous issues for python-dev. The crowd just is conservative (which is a good thing may I say for something like python). Although I have never contributed much to pywin32, I can give you my experience with git/bzr/hg and what happened with numpy, where we moved from svn to git. I think the so-called easiness of hg vs git is superficial. It is true that git command line UI is inconsistent, and a lot of doc too detailed. But its concepts are as simple as hg if not simpler. As for an example: hg still does not know how to deal with branches IMO, in the sense that you have several branch concepts (named branches vs bookmarks vs clones), all with different UI and different level of support from the tools. As soon as you want to share work based on branches, you all have to agree on which process to use. It is then not that much simpler, especially since bookmarks and named branches have quite a few WTF (for example you can have multiple named branches with the same name). The argument that hg can do everything git can is kind of true (module the index, which is unique to git AFAIK), but you certainly have to dig into things which are not even in the hg book to do things which are routine in git. What I can do with ~15 commands in git, I need mercurial queues and numerous extensions in hg (which I have to use at work). Hg does have objective advantages over git: it is in python, and it is easier to use for a significant crows on windows. This was not a big issue for numpy, but may be for pywin32 given its purpose. cheers, David _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
