

Codeplex donates $25,000 to Mercurial - NumberFiveAlive
http://blogs.msdn.com/b/codeplex/archive/2010/09/06/codeplex-com-donates-25-000-to-mercurial-project.aspx

======
paulitex
Fantastic. Though what Mercurial needs even more than Matt's full time
attention is a really good forge. Bitbucket just really doesn't hold a candle
to Github (and codeplex is pretty unattractive for anyone not a microsoft
dev).

It's a genuine problem (for me at least) when starting a new project -
bitbucket (-) and Mercurial (+) or github (+) and git (-). If anyone from
github is reading this - please consider first-class Mercurial support. It
would almost definitely be easier for you to do this than for bitbucket to
make up the gap.

(I know lots of people prefer git, but Github already has that market pretty
cornered. There is an opportunity among those who prefer hg.)

~~~
cageface
What is it about HG you prefer? Git and HG seem pretty comparable as far as
features go but github seems to have all the momentum.

~~~
stevelosh
I'm not the OP, but I'll give my reasoning for preferring Mercurial: its CLI
has commands that each do _one thing_ instead of commands that have options to
do anything.

For example: `git checkout` can change the contents of files without changing
where you are in the DAG, change where you are in the DAG, and even create a
new branch. In Mercurial you'd use three separate commands for these things:
`hg revert`, `hg update`, and `hg branch`.

The problem with git's approach is this: making every command very flexible
through options means that you need to document the interaction of all these
options in the man pages. That makes the documentation for each command harder
to read, especially when you're in the middle of trying to get something done
with a project and just want to do something quickly.

For a real example, look at the help for the two SCMs' commands for changing
the contents of a file:

    
    
        $ (hg help revert) | wc -l
              47
        $ (git help checkout) | wc -l
             276
    

Some might say: "But `git checkout` can do so much more than `hg revert`!"
That's absolutely true. However, every time I want to look up how to revert
file contents I need to wade through hundreds of irrelevant lines in git's
documentation. When I'm using Mercurial I say "Well, I know I need to use `hg
revert`, let's just look at those 47 lines of help and find out what exactly I
need."

When you combine the help for the equivalent Mercurial commands it's _still_
more succinct than git's help, because splitting individual actions into
different commands means you don't have to document interactions between
options:

    
    
        $ (hg help revert; hg help update; hg help branch) | wc -l
             113
        $ (git help checkout) | wc -l
             276
    

TL;DR version: Git's decision to make its CLI's commands very flexible results
in painful documentation, so I perfer Mercurial.

~~~
snprbob86
I learned Mercurial first and found the vast majority of its commands to be
highly intuitive for the 4 core actions of a distributed version control
system

1) Check-pointing code 2) Jumping back (or sideways) in time 3) Sending code
to others 4) Receiving code from others

However, once I really understood the distributed version control model, I
found myself thinking in terms of the DAG and wanting more control over it. I
started viewing my version control system as a tool for more than just version
control. I started viewing it as a tool for understanding and communicating
about my code. I started using it as a tool to manipulate my code.

Then, for one small project, I tried Git. It drove me NUTS for about a week. I
was going to smash things. I was so angry about it using stupid cryptic terms
for simple things. I was annoyed by the complexity of overloaded, highly
flexible commands. But once I translated the vocabulary, the commands stopped
seeming so complex. Instead, they seemed like a reasonable abstractions. Each
of the sub-operations they can perform are really just specializations of one
kind of operation. It became second nature. I started doing swiss-army-knife
voodoo with Git that Mercurial could only accomplish with a giant pile of
half-baked plugins, blood, sweat, and tears.

Now, I only use Git.

tldr: Git is a more abstract, more powerful tool than any mere version control
system. This is only something you come to appreciate with experience.

~~~
lars512
Can you provide a concrete example of DAG editing which you had trouble doing
with Mercurial?

~~~
snprbob86
From things as simple as "git stash" to anything you'd use Mercurial's MQ
extension for and beyond. Also, the Index, a concept which I initially wrote
off as a frustrating extra step, turns out to be super useful for moving
around chunks of code quickly.

------
walkon
Perhaps they have or will soon, but you'd think Fog Creek (Joel Spolsky) would
want to donate a bit as well since Kiln revolves around Mercurial:

<http://www.fogcreek.com/kiln/>

~~~
KTamas
Except Fog Creek is a gold sponsor already:
<http://mercurial.selenic.com/sponsors/>

~~~
walkon
Ah, very good, that's why I said, "perhaps they have" - thanks for the link.

