
Python switching to Mercurial - davidw
http://mail.python.org/pipermail/python-dev/2009-March/087931.html
======
jballanc
I'm am a fan and proponent (but not quite fanboy) of Git... but I think this
is excellent news! First, with Mercurial implemented in Python, this is a
great case of "eat your own dog food".

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 ;-).

~~~
cstejerean
Until we get excellent interop between git and mercurial I'm not buying the
argument that git vs hg is anything like vi vs emacs.

~~~
biohacker42
Git has excellent interop with CVS, so I imagine excellent interop between Git
and other DVSs is in our near future.

\-- EDIT --

By excellent interop with CVS I obviously mean the one way CVS to Git. I'm
hoping Git/Hg will go both ways.

~~~
jballanc
Git's pretty good going two way with Subversion. If nothing else, perhaps
Subversion could be a poor man's bridge for the time being?

------
davidw
I had thought that git was rolling towards a dominant position in this space,
however:

> 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.

~~~
mechanical_fish
I think submodules are a bit of a failed experiment, yes. Or, perhaps, a work
in progress. Their usability is just awful. That said, if you don't use them
the rest of git works just fine. ;)

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...](http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension)

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.

~~~
davidw
svn's externals work quite well, on the other hand. I know, I know, svn is
_so_ 2007, but after fiddling around a bit with git, my impression is that
spending time writing code is an order (if not more) of magnitude more
important thank screwing around with a version control system, and svn mostly
'just works'. I think that eventually things like git and hg will surpass it,
but version control isn't where your startup is going to "make or break" it
(unless you're github:-).

~~~
SwellJoe
_svn's externals work quite well_

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.

~~~
davidw
Ok, so they're not perfect, but "hassle" beats "silently discarded" any day.

------
w1ntermute
" _At PyCon, Brett already announced that Git was no longer being considered
-- while it has obviously many fans, it also provokes strong antipathies._ "

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?

~~~
pjhyett
I'm not sure why you're being down-modded.

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."

~~~
etal
The way I read it, and the document discussing the VCS switch (PEP 374), was
that the Big Three DVCSes (git, hg, bzr) were essentially all just fine. Git
is the fastest and hairiest, Bazaar is the slowest and cutest, and Mercurial
covers both ends fairly well without introducing any glaring flaws. All three
systems have big, well-known projects actively running on them, with
developers singing about how much better their respective choices are compared
to the SVN or CVS systems. Any choice would have been fine; it was fairly
obvious.

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.

------
jhawk28
Good news for Mercurial. It happens to be my favorite DVCS. Bruce Eckel seemed
to come to the same conclusion (HG over BZR). It just seems to have the right
feel after coming from Subversion. All in all, it is good competition. Git
needs to get a smoother feel on Windows, BZR has a lot going for it - but
needs to find that polish, hg needs to add first class SVN support, and SVN
needs keep from stagnating or changing too much.

------
benhoyt
Cool, and I like Guido's way of making decisions. But I'm just wondering why
they're switching. Did they find that Subversion wasn't working for them?

~~~
benhoyt
Oh, I see. PEP 374: <http://www.python.org/dev/peps/pep-0374/>

------
bcl
I think this is a good choice. I found learning mercurial after using svn for
years to be very easy. And why not choose a system written in the language
that you are writing? Sort of a recursive dog food feast...

------
axod
Hedging their bets?

murcurialhub.com is registered by github

~~~
graywh
Github mostly provides the pretty web interface. There's no reason they
couldn't do the same for the hg crowd. So, not so much hedging their bets, but
looking to expand?

~~~
jonknee
BitBucket does a web interface for hg already. It's not as social as GitHub,
but I'm a fan (and subscriber).

~~~
jmtulloss
I want to see github buy BitBucket and integrate the two cleanly. Being able
to use git OR mercurial for any repository on *hub would be awesome.

------
100k
The battle has been joined. ;)

Seriously, though, it's probably a good fit. Mercurial is written in Python,
after all.

~~~
rcoder
More importantly, Mercurial is _extensible_ in Python -- you can write
extension modules, hooks, etc., all of which have full access to the (albeit
poorly-documented) Mercurial internals.

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.

------
tommyx
Should be interesting to see whether Mercurial will grow or maintain
marketshare.

------
thorax
This is great-- I had recently started my own Python mercurial repo for minor
changes we had to make for embedding it into the Source engine. This will make
it easier for us to keep in sync with base.

------
intellectronica
I am thrilled that Python is switching to a python-based DVCS, but I'm bitter
about Bazaar not being the choice :-/

~~~
jobenjo
Yeah, after reading his explanation, I wished I'd chimed in and said I'm a
non-Canonical coder who's been really happy with Bazaar.

