Python switching to Mercurial
mail.python.org
mail.python.org
Second, I want competition in the SCM space. I think the biggest tragedies with Subversion and CVS before it was that their dominant positions implied that there was "only one way" to do SCM. Hopefully, by keeping at least two competitors around, there will be more stimulus for invention and improvement.
...sure, it'll make developers live a bit harder, as now there is yet another decision that needs to be made. But come now! If developers can decide between Vi and Emacs, surely they are capable of deciding between Git and Mercurial (and no...don't even try to tell me there are more than two choices for text editor ;-).
-- EDIT --
By excellent interop with CVS I obviously mean the one way CVS to Git. I'm hoping Git/Hg will go both ways.
> At PyCon, Brett already announced that Git was no longer being considered -- while it has obviously many fans, it also provokes strong antipathies.
And I'm starting to see why. It has... issues. One I ran into recently:
http://book.git-scm.com/5_submodules.html
> It's not safe to run git submodule update if you've made and committed changes within a submodule without checking out a branch first. They will be silently overwritten:
"Silently overwritten" are not words you want to be associated with a version control system.
Does Mercurial support submodules or the equivalent? Not in core, from what I can tell, although a casual search of Google reveals the third-party "Forest Extension":
http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtens...
There's some talk on a wiki about putting this extension's functionality into Mercurial proper, but the wiki link is broken. That doesn't bode well. I don't know Mercurial so I have no idea if Forest is actually being used by folks, if it's akin to git submodules or more akin to Braid, if it's got usability traps of its own, etc. The docs page is filled with TODOs.
Although, actually, I'm pretty sure you can get git projects with submodules to roll back to consistent states. But it might take ten separate commands, five attempts, and a visit to the FAQ. Submodules are conceptually tricky and their workflow is a mess.
I've got some notes on the subject on my blog:
http://codeintensity.blogspot.com/2008/03/svn-externals-are-...
He strikes me as someone who has come by this lesson through direct, painful personal experience.
I've settled on Braid for the moment, and we'll see how that goes. Submodules offer more features, but at the expense of my ability to explain them to anybody else.
I found them quite painful. Links to external paths don't work, committing with multiple externals when one or more of the external repos are down has some sort of problem (though it's been a while and may have been fixed), doing anything from the external to the parent (like moving files) had some sort of problem as well (again, maybe fixed). It was enough of a problem that the project I was working on ended up with two repositories for the same code...and they would manually merge them periodically. Obviously sub-optimal and a big waste of time, but it was less trouble than the alternative of having every developer understand why the external repo had to be treated completely differently from the rest of the repository in many regards.
Mercurial = Python-based = runs anywhere Python runs
Git = Unix-like systems only
Doesn't Python shelter a decent sized Windows community? (Free, more accessible than the Windows flavors of Perl / Ruby)
Curiously, this was part of the reason Python chose not to use Git even after extensive research. One would have thought they would have stumbled across any number of projects like msysgit that would have shown them otherwise.
It does work, once you answer a question of which of three ways it should awkwardly integrate into your PATH, but within a cygwinesque bash shell.
So yeah, functional but nowhere near as smooth and seamless as python on windows is, or as one might pick up from your comment.
Vienna-2:libgit2 pieter$ git commit -am "wawaa"
[detached HEAD 8641889] wawaa
Of course, your changes aren't lost after the update. You can still get access to them from the reflog ('git reflog') or a simple "git checkout @{1}"
Second, where are all these points whenever someone asks about git? All you ever seem to get in return are fanboys trumpeting git as the second coming, even here on HN.
If you go looking for rough edges in an open-source Unix power tool that's under development... you're going to find them.
Based on my research (but, please note, not much actual experience) git submodules are ugly, confusing, and perhaps even dangerous in the hands of anyone but an expert. I avoid them. That said, it appears that lots of Rails developers use them every day and can't live without them. Should this feature have been kept out of the official git release, just because it's still being worked out? Not an easy question to answer. Every project maintainer has a different philosophy about such things, and there are a lot of judgement calls to be made.
What I take issue with however is that these warts get conveniently forgotten in the buzz. Even worse, I'd be willing to bet that most of those rails dev's have no idea what is solid and what's a work in progress; they're being done a disservice, really.
I suppose my concern is that there's a fine line between enthusiasm and hype, and it's difficult to know when you've crossed the line.
The problem, to paraphrase Tolstoy, is that happy users are all alike, but every unhappy user is unhappy in her own way.
It's easy to write a review that talks about the core features that a tool gets right. Everyone cares about those features, and everyone uses them, and they're well documented. It is much harder to write a review containing a categorical list of warts. Warts are incidental problems that only bother a subset of users. (If they bothered absolutely everybody, they wouldn't be called warts; they'd have a different name: bugs or misfeatures.)
Worse, one person's wart is another person's feature. Legions of people have complained, over the decades, that rm has a horrible and dangerous UI which lets you accidentally erase your entire machine by typing a stray space at the wrong time. But, somehow, rm persists, because there are plenty of power users who like it.
Is anyone here involved closely in the python community who could maybe shed some light on what made git inadequate for their needs?
Besides being able to say they're eating their own dog food, I think having the ability to easily extend their version control system was a factor in the choice. The Python developers would just be writing Python, after all, and Mercurial has a very simple extension system.
I believe Guido has had direct communication with some of the core developers of Mercurial as well, which was probably another factor. I'm not sure what Brett's DVCS usage survey had to say about Mercurial or Git, but that could also play a role in his decision.
Here's the original thread that led up to the PEP: http://thread.gmane.org/gmane.comp.python.devel/98191. From what I understand, there wasn't supposed to be a lot of discussion until the PEP was written, but people couldn't help but voice their opinions on the matter. I'm guessing this is why Guido put his foot down: to prevent an endless religious debate. Hopefully the PEP will be revised with a more detailed explanation of his rationale.
This seems illogical at best. They chose not to use Git because there are a lot of people that dislike it? This decision should have been based on technical details, not on feelings. Anything else is doing a disservice to the developers and to the community. How many other VCS's were passed up because they had a lot of haters?
Since they aren't sharing any of these details, we have no choice but to assume there are none. In fact, their exact reason for not using Git was "it also provokes strong antipathies". That doesn't even _imply_ technicality on any level.
Either way, I couldn't care less personally. The only people they're hurting are themselves, as a gateway can be created between Git and Mercurial. All the projects I work on right now use SVN, and I just use git-svn for everything.
The Python team purporting to do DVCS research and then saying their decision was made on a gut feeling seems disingenuous at best.
Sure, I'm biased because I work for GitHub, but this decision would have felt like much less of a slap in the face had they just said: "We're switching to Mercurial because we like it and it's written in Python, case closed."
Python has a history of fussy programmers. Remember the web framework wars of a few years ago? Everyone complained that there were too many choices, picked favorites to champion and nitpicked at the alternatives (which were not actually bad), and nobody could sleep at night because there were alternatives and nobody knew which one was right. Then Guido announced that Django was right, and the lost souls breathed a sigh of relief and did the Django tutorial, and the folks who were already using Turbogears and Pylons productively continued to do so. Django isn't necessarily the best Python web framework for everyone, but it's rarely a bad choice.
That's pretty much what happened this year with DVCSes. The Biopython project was stalled on a CVS-to-SVN transition for over a year, for example, until some grenades were thrown and tears were shed and finally Git was picked because a few people liked it, nobody really had a problem with it and all the other options were triggering nasty blog posts. Case closed. Sometimes we just need a quick slap to shut us up.
And I can understand how you would wish they used git, but if you're taking this as a "slap in the face" at all, I think you're reading it wrong. They did some research on various similar tools and picked one.
My problem is not with their decision, but with how they made it. They are taking the "cathedral" approach, rather than the "bazaar" one.
Also known as "weasel words": http://en.wikipedia.org/wiki/Weasel_word
murcurialhub.com is registered by github
Seriously, though, it's probably a good fit. Mercurial is written in Python, after all.
Writing extensions for Git is rather different, since you effectively can't. To extend or build on Git, you end up doing a lot of shelling out to the 'git' binary with use of 'raw' output formats and regexp-based scraping. It's pipes and shell subcommands all the way down, instead of a library-style programming API.
Which you prefer depends a lot on the diversity and preferences of the community using your repositories. Mercurial pushes you towards usability and single-language (Python) solutions, while Git easily drops into a classic UNIX-like "lots of little scripts" solution.