On 03.01.2009, at 4:25, Nikolai Weibull wrote:

> Or at least get our facts straight and present valid cases for the
> SCMs that we prefer?


I use Git and Mercurial every day: Git for work and open source  
projects, and Mercurial for all my personal
documents, emacs.d, tools, configuration files. I happened to use  
Darcs for about a month. Now here is my perspective.

First, don't trust me when I say something about Windows support below,,
simply because I do not use Windows. I can't say if msysGit still has  
significant problems or not,
I'd trust Luis Lavena on this.

Another note: I am 10000% ok with using Hg instead of Subversion
or Bzr instead of Subversion, but because this thread moved to "git vs  
hg vs bzr vs darcs vs git-is-for-nerds-well-not-really vs freebsd-is- 
not-linux-you-mofos,
I just want to waste some time and tell my personal experience with  
them.

if you are really interested in a summary, read Learning curve section  
and the last section. Others
are mostly noise.


Learning curve vs. Feature richness:

Git has learning curve, but once you get it, it *is* as simple to use  
as any other VCS. But
when you hit the wall and you need an "advanced" feature
(from "what commit introduced this issue" to "what subcomponents of  
the project change
more often and thus need more attention"), it literally can do
wonderful things.

Mercurial is easier to learn, and it feels more like home for  
Subversion users. Even commands are
pretty much the same, though bringing in some new concepts and trying  
to tie them to existing
vocabulary of the SVN world leads to more confusion in certain cases  
(ex.: update/merge).
It has pretty much any feature Git has, but sometimes you have to go  
and install plugins to get them.
And some plugins are plain stupid, hg log does not use pager by  
default, but a pager plugin forces
*every* single command to go through a pager, which is not really what  
you want. But in general,
I have no plans of moving my personal stuff from Mercurial.

Won't pretend to know the Bazaar situation, but I think it is on par  
with Mercurial, and is quite
friendly, and has everything you possibly may need either built in or  
as plugins.

Darcs is quite friendly and interactive, which looks very nice at  
first, but later when you try to
merge with the rest of the team, and screaw up with all this "pick a  
hunk" interactive awesomeness, you either
try to avoid all this interactive stuff, or it brings as much  
irritation as pleasure initially. So
Darcs is the most nerdy, not Git.


Branching and merging:

Git stores all the local branches in a single working copy, and you  
can switch between them,
delete them, rename them, etc in one physical directory on your HD.
I always preferred this approach to say what Mercurial has, though it  
is not crucial.
Since branching/merging is essential part of the process Git was  
created for, it has
all the features in the world related to branching, and more: fetch/ 
pull to confuse people who
barely know how "push" is different from "commit"; rebase so you have  
a way to screaw up
even if you think of yourself as of advanced user; and other fun  
things ;)
But 95% of the time you can do the job without them, and Git brancing/ 
merging can be distilled to like 3-4
commands you can easily explain in a contributors guide.


Darcs has idea of "every branch is a separate directory" (or used to  
have it). I can't
say it is a problem but you will end up having 3-5 copies of the  
pretty much the same
code, and if you repository is 600 megs, not all movies you try to  
download from iTunes may
fit into your HD.


Mercurial has local repository branches, but you... cannot delete them  
without touching
your nose with yout foot first! There are special plugins that try to  
provide this sort of
functionality, and none of them really did what Git has when I tried.  
So, for long living
branches you end up having directory copies, just like with Darcs, and  
like I said,
it sounds like an ugly thing to me. Again, we are sacrificing that hot  
new Angelina Jolie
movie downloaded by iTunes/Miro, so maybe it is a big deal for some.

I cannot really judge bazaar here, but looks like again, it is  
directory copies here
and there. Maybe this thing is some golden standard of DVCS world Git  
developers had
no idea about.



Sharing of repositories:

I only mean technical aspect here, GitHub vs. the rest of the world  
discussion comes
at the end of this message. All git, darcs, bzr, hg can use SSH and  
HTTP to sync with
remote repositories, and have
some sort of web UI if you really need it. What else would you wnat?



Really useful features vs Crap you never use:

bisection, a *very* useful feature, is supported by each and every of  
them. Stashed
commits, squashed commits (merge 100 commits as one large) and  
rebases, things that
advanced users like for a real reason, are supported by every system I  
think.

The rest is something 99% of the population does not use.


Performance:

I don't know why people who maintain projects even of Rails size care  
so much about Git
being super fast, it should be a problem for KDE and gcc and not Ruby  
libraries.

But. Git performs the best, Mercurial and Bazaar are very fast, too.  
Mercurial, in fact,
is so fast I used it on a very old (5 years or so) machine and never  
though that it is
written, to large extent, in a very high level language. Darcs is  
probably slowest,
but not too slow anyway.

So unless MRI grows to the size of gcc, which I hope will never  
happen, they all perform
reasonably well or better.



UI front ends and tools support:

A note for Emacs users: vcs-mode backends are available for at least  
git/hg/bzr, and the
keymap is the same. So, you may not even notice that you have hg and  
not git under the hood.
magit, gitsum and a bunch of Hg modes available for those who need it.  
Win!

Vim users may chill out and stop screaming "we have it too, and  
better!!!", we all know ViViVi is The Devil's Editor,
and one day the higher power will remind us of our sins, but I am sure  
vim has a counter part for every
Emacs feature ;)

NetBeans has support for Hg out of the box, Eclipse has plugins I  
cannot really judge... not sure how many MRI contributors
use those behemoths.

Git has like 3 or 4 standalone UI programs for OS X, a couple for  
Linux and probably has no UI tools
on Windows.

Mercurial said to have a good Windows tool (TortoiseHg), but on OS X  
and Linux it is a
completely different story. I never really used a UI tool on OS X, but  
I know some people
who were looking for one, and what they found was miserable.

I have no idea what Bazaar has but it probably does better than Hg  
since Canonical cares about less technical users.
Darcs seems to be lacking UI tools altogether.



There will be bugs:

If something goes wrong with Git, you have a very vibrant community  
support, and bug fixing
process is pretty fast. Mercurial and Darcs are in Python, which  
means, you even can
even try to fix the problem yourself in a reasonable amount of time.  
Darcs is in Haskell,
and has the smallest community of them all, so unless you are functional
programming geek, the first time you come around a bug, it is probably  
gonna be the last time you used Darcs.



Availability of Github:

Now, to the crucial part. Everything you read above simply does not  
really matter.
Because GitHub is only available for Git. Hg, bzr, darcs all lack  
github.
They may have launchpads, space ships and invented a way to store bits  
in a bitbucket, but they lack
GitHub. And GitHub totally changes the way people work on open source,  
the way it should be.

Open source is about project ecosystem and how parts (developers,  
companies) of that ecosystem
interact. With GitHub you don't have to invent ways of collaboration,  
tools to visualize
what you want to see, and simply poking that guy who created that cool  
thing but introduced
a bug that you fixed and want to push upstream.

Bitbucket and Launchpad may be both great code silos, provide wikis,  
trackers and so forth,
but they miss the crucial point: forking, pull requests and merging  
should be so simple
13 y/o can do it, and GitHub gets this part right.

Seriously, what made a lot of projects in the Ruby community switch to  
Git? The fact that
it is "new hotness"? Performance? The fact that Hg and bzr are in  
Python? Linus Torvalds
fanatism? Marking efforts of Chris, Tom, PJ and co?
No. Ease of collaboration that is not really possible without GitHub  
at this moment.

MK