SDL in Mercurial!

This is my test attempt at converting the SDL Subversion repository to
Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named branch.
All revision history in the Subversion repo (back to 1.2.0) is in the
Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk
this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve read a
    lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop fearing
    branching. Mercurial works best when you have a bunch of little ad-hoc
    branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the summary.

  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you
    start using things that Subversion can’t do (bisect, record, shelve,
    rollback, queues, etc), you’re going to find yourself annoyed when you
    have to work with a Subversion repository and can’t use these extra
    features.

Comments and questions welcome.

–ryan.

Oh awesome!> -----Original Message-----

From: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] On Behalf Of Ryan C. Gordon
Sent: Friday, February 26, 2010 7:50 PM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL in Mercurial!

This is my test attempt at converting the SDL Subversion repository to
Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to
replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named branch.
All revision history in the Subversion repo (back to 1.2.0) is in the
Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk
this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of
bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve read a
    lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop fearing
    branching. Mercurial works best when you have a bunch of little ad-hoc
    branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the summary.

  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you
    start using things that Subversion can’t do (bisect, record, shelve,
    rollback, queues, etc), you’re going to find yourself annoyed when you
    have to work with a Subversion repository and can’t use these extra
    features.

Comments and questions welcome.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That’s a great Mercurial tutorial! :)On Fri, Feb 26, 2010 at 7:49 PM, Ryan C. Gordon wrote:

This is my test attempt at converting the SDL Subversion repository to
Mercurial.

? http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again while I
play around. Eventually, this will move to libsdl.org to replace the
Subversion repository.

This is just SDL; I have filtered out the other projects and spent a great
deal of time hand-editing the Subversion dump to clean up the revision
history, and will be packaging them in separate repos. This repo has the 1.3
branch as the default, and SDL-1.2 as a named branch. All revision history
in the Subversion repo (back to 1.2.0) is in the Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk this
eats:

$ du -hs SDL-hg
100M ? ? SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of bytes, but
that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and branches/SDL-1.2
from Subversion:

$ du -chs SDL SDL-1.2
50M ? ? SDL
37M ? ? SDL-1.2
86M ? ? total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the revision
history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new hginit.com.
    You should read it. It’s interesting and funny. I’ve read a lot of
    quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop fearing
    branching. Mercurial works best when you have a bunch of little ad-hoc
    branches weaving around each other.

  • When committing new changes, keep the first sentence of the log comment
    short and on a line by itself. It’ll be used for the summary.

  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you start
    using things that Subversion can’t do (bisect, record, shelve, rollback,
    queues, etc), you’re going to find yourself annoyed when you have to work
    with a Subversion repository and can’t use these extra features.

Comments and questions welcome.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Not awesome. If it ain’t broke, don’t fix it, and the SVN server isn’t
broke. It’s not that we “fear branching,” it’s that we don’t really need
the added features that Mercurial brings to the table, and it’s not
worth all the extra hassle of reimplementing a working system to get
functionality that SDL’s development has never needed, and then
having to adapt to new paradigms to take full advantage of it! That’s
just plain ridiculous IMO.>----- Original Message ----

From: Tres Walsh <tres.walsh at gmail.com>
Subject: Re: [SDL] SDL in Mercurial!

Oh awesome!

-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] On Behalf Of Ryan C. Gordon
Sent: Friday, February 26, 2010 7:50 PM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL in Mercurial!

This is my test attempt at converting the SDL Subversion repository to
Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to
replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named branch.
All revision history in the Subversion repo (back to 1.2.0) is in the
Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk
this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of
bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve read a
    lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop fearing
    branching. Mercurial works best when you have a bunch of little ad-hoc
    branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the summary.

  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you
    start using things that Subversion can’t do (bisect, record, shelve,
    rollback, queues, etc), you’re going to find yourself annoyed when you
    have to work with a Subversion repository and can’t use these extra
    features.

Svn is simply outdated though. So, in a sense it IS broke.
If you are working on something in svn, then you can’t drop what you
are doing and try a spur of the moment fix / feature, you must stop
your work, create a patch, revert your changes, the do what you wanted
to do in the first place, then once that is done, either commit or
revert your current stuff, and then, finally reapply the patch you
made in step A.

A huge waste of time, and a productivity killer.

With hg, you just shelve the changes, and come back to them at a later point.
It really makes the job of developing much easier, and less tedious.

The only big question here is how does hg handle EOL on windows
systems (aka CRLF <-> LF conversions).On 2/26/10, Mason Wheeler wrote:

Not awesome. If it ain’t broke, don’t fix it, and the SVN server isn’t
broke. It’s not that we “fear branching,” it’s that we don’t really need
the added features that Mercurial brings to the table, and it’s not
worth all the extra hassle of reimplementing a working system to get
functionality that SDL’s development has never needed, and then
having to adapt to new paradigms to take full advantage of it! That’s
just plain ridiculous IMO.

Svn is simply outdated though. So, in a sense it IS broke.
If you are working on something in svn, then you can’t drop what you
are doing and try a spur of the moment fix / feature, you must stop
your work, create a patch, revert your changes, the do what you wanted
to do in the first place, then once that is done, either commit or
revert your current stuff, and then, finally reapply the patch you
made in step A.

A huge waste of time, and a productivity killer.

…huh? I’m sorry, but I have no idea what you’re talking about there.
A file is a file, and you can modify them just fine no matter what
version control system you’re using, without long and convoluted
backup/patch/restore/whatever cycles.

If I’m working on something in SVN, and I need to create a quick
patch, I create the patch, check in only the files involved in the
patch, leave the patch in my codebase because I most likely
created the patch to solve a problem I was having in the first
place, and then go back to what I was doing originally.

The only possible scenario I can think of where this would
even potentially be problematic is if you’re working on
something and then, halfway through, have to patch an
unrelated issue in the same file, which I’ve never actually
had happen to me. Is that what you’re referring to?>----- Original Message ----

From: buginator
Subject: Re: [SDL] SDL in Mercurial!

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos.

And here they are…

http://hg.icculus.org/icculus/SDL_image/
http://hg.icculus.org/icculus/SDL_mixer/
http://hg.icculus.org/icculus/SDL_ttf/
http://hg.icculus.org/icculus/SDL_rtf/
http://hg.icculus.org/icculus/SDL_net/
http://hg.icculus.org/icculus/sdlweb/
http://hg.icculus.org/icculus/Maelstrom/

…I’m probably going to rebuild the base SDL repo with the revisions
sorted by branch…it’s a little ugly for what eventually becomes
ancient history, but it makes the repo about 60 megabytes instead of 100
(and yes, that’s smaller than the 1.3+1.2 Subversion checkout).

–ryan.

Not awesome. If it ain’t broke, don’t fix it, and the SVN server isn’t
broke. It’s not that we “fear branching,” it’s that we don’t really need
the added features that Mercurial brings to the table, and it’s not

As someone that pulls from the repo, you won’t see a big different
(you’ll type “hg fetch” instead of “svn update”). But as someone that
commits work to the repo: trust me, it’s a good step.

–ryan.

The only big question here is how does hg handle EOL on windows
systems (aka CRLF <-> LF conversions).

You enable an extension (shipped with Mercurial) in your config file.
The repo always wants to store in Unix endline format, and the extension
will convert to and from Windows format when used on a Windows machine.

(and it does basic heuristics to make sure you’re really using a text
file it should be converting.)

http://mercurial.selenic.com/wiki/Win32TextExtension

If you’re using Cygwin or some such environment, you may want to just
stick with the Unix endlines, of course.

–ryan.

I have to agree with Mason here.

Being an IT consultant in the real world, and having spent half of my
working years
as SCM/Build manager, I fail to see the advantage here as well.

I hardly contribute any code to SDL, so my voice is worth zero on this
issue, but this looks
like all those real life cases I have witness, where a company changed their
complete build
infrastructure just because one of their managers decided to change to the
flavour of the month.

So what are the real benefits Mercurial will bring to SDL developers,
besides some new cool
features, that you might use?

How will be the expected productivity gains?–
Paulo

On Sat, Feb 27, 2010 at 5:39 AM, Mason Wheeler wrote:

Not awesome. If it ain’t broke, don’t fix it, and the SVN server isn’t
broke. It’s not that we “fear branching,” it’s that we don’t really need
the added features that Mercurial brings to the table, and it’s not
worth all the extra hassle of reimplementing a working system to get
functionality that SDL’s development has never needed, and then
having to adapt to new paradigms to take full advantage of it! That’s
just plain ridiculous IMO.

----- Original Message ----
From: Tres Walsh <tres.walsh at gmail.com>
Subject: Re: [SDL] SDL in Mercurial!

Oh awesome!

-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] On Behalf Of Ryan C. Gordon
Sent: Friday, February 26, 2010 7:50 PM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL in Mercurial!

This is my test attempt at converting the SDL Subversion repository to
Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to
replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named branch.
All revision history in the Subversion repo (back to 1.2.0) is in the
Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk
this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of
bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve read a
    lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop fearing
    branching. Mercurial works best when you have a bunch of little ad-hoc
    branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the summary.

  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you
    start using things that Subversion can’t do (bisect, record, shelve,
    rollback, queues, etc), you’re going to find yourself annoyed when you
    have to work with a Subversion repository and can’t use these extra
    features.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’ve seen projects convert from SVN to Git and see huge increases in
the amount of contributions, largely because of the distributed nature
of the revision control system. With Subversion, the "commit access"
thing is probably more of a pain than most people realize.
Contributors have to do all sorts of painful things to make patches
work with newer revisions, and it gets messy really fast. This really
discourages contribution. Whereas, with something like Mercurial or
Git, you can very easily rebase your work on top of the latest code.
And being able to just “pull” changes into a repository is a huge help
for maintainers as well.

If you want to see a “for instance” of Git helping a project’s
productivity, just take a look at Dungeon Crawl Stone Soup. We
switched from SVN to Git in about September or October, and we’ve been
very pleasantly surprised with the development pace and number of
contributions.

I would not so quickly dismiss a move to Mercurial.

  • StevenOn Fri, Feb 26, 2010 at 10:48 PM, Paulo Pinto wrote:

I have to agree with Mason here.

Being an IT consultant in the real world, and having spent half of my
working years
as SCM/Build manager, I fail to see the advantage here as well.

I hardly contribute any code to SDL, so my voice is worth zero on this
issue, but this looks
like all those real life cases I have witness, where a company changed their
complete build
infrastructure just because one of their managers decided to change to the
flavour of the month.

So what are the real benefits Mercurial will bring to SDL developers,
besides some new cool
features, that you might use?

How will be the expected productivity gains?


Paulo

On Sat, Feb 27, 2010 at 5:39 AM, Mason Wheeler wrote:

Not awesome. ?If it ain’t broke, don’t fix it, and the SVN server isn’t
broke. ?It’s not that we “fear branching,” it’s that we don’t really need
the added features that Mercurial brings to the table, and it’s not
worth all the extra hassle of reimplementing a working system to get
functionality that SDL’s development has never needed, and then
having to adapt to new paradigms to take full advantage of it! ?That’s
just plain ridiculous IMO.

----- Original Message ----
From: Tres Walsh <tres.walsh at gmail.com>
Subject: Re: [SDL] SDL in Mercurial!

Oh awesome!

-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] On Behalf Of Ryan C. Gordon
Sent: Friday, February 26, 2010 7:50 PM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL in Mercurial!

This is my test attempt at converting the SDL Subversion repository to
Mercurial.

? ? http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to
replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named branch.
All revision history in the Subversion repo (back to 1.2.0) is in the
Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk
this eats:

$ du -hs SDL-hg
100M ? ? SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of
bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M ? ? SDL
37M ? ? SDL-1.2
86M ? ? total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve read a
    lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop fearing
    branching. Mercurial works best when you have a bunch of little ad-hoc
    branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the summary.

  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you
    start using things that Subversion can’t do (bisect, record, shelve,
    rollback, queues, etc), you’re going to find yourself annoyed when you
    have to work with a Subversion repository and can’t use these extra
    features.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I don’t want to dismiss it, I was just pointing out what are the real
reasons to change the SCM
in use.

SDL already changed from CVS to SVN, and Subversion has lots of nice
features over CVS that
are really worth the upgrade, like the ability to rename directories.

Now I was just being sceptic about the gains. Do the majority of the SDL
contributors face daily
issues that would be solved by moving to Mercurial or it is a solution in
search for a problem?

If in 2 years time there is the new XYZ source control will it move again?

As I said, I hardly contribute any real code to SDL so my voice doesn’t
really count here, but I fail
to see the beneficts. Maybe I am too old and have seen this type of scenario
too many times already.–
Paulo

On Sat, Feb 27, 2010 at 8:00 AM, Steven Noonan wrote:

I’ve seen projects convert from SVN to Git and see huge increases in
the amount of contributions, largely because of the distributed nature
of the revision control system. With Subversion, the "commit access"
thing is probably more of a pain than most people realize.
Contributors have to do all sorts of painful things to make patches
work with newer revisions, and it gets messy really fast. This really
discourages contribution. Whereas, with something like Mercurial or
Git, you can very easily rebase your work on top of the latest code.
And being able to just “pull” changes into a repository is a huge help
for maintainers as well.

If you want to see a “for instance” of Git helping a project’s
productivity, just take a look at Dungeon Crawl Stone Soup. We
switched from SVN to Git in about September or October, and we’ve been
very pleasantly surprised with the development pace and number of
contributions.

I would not so quickly dismiss a move to Mercurial.

  • Steven

On Fri, Feb 26, 2010 at 10:48 PM, Paulo Pinto <@Paulo_Pinto> wrote:

I have to agree with Mason here.

Being an IT consultant in the real world, and having spent half of my
working years
as SCM/Build manager, I fail to see the advantage here as well.

I hardly contribute any code to SDL, so my voice is worth zero on this
issue, but this looks
like all those real life cases I have witness, where a company changed
their
complete build
infrastructure just because one of their managers decided to change to
the
flavour of the month.

So what are the real benefits Mercurial will bring to SDL developers,
besides some new cool
features, that you might use?

How will be the expected productivity gains?


Paulo

On Sat, Feb 27, 2010 at 5:39 AM, Mason Wheeler wrote:

Not awesome. If it ain’t broke, don’t fix it, and the SVN server isn’t
broke. It’s not that we “fear branching,” it’s that we don’t really
need

the added features that Mercurial brings to the table, and it’s not
worth all the extra hassle of reimplementing a working system to get
functionality that SDL’s development has never needed, and then
having to adapt to new paradigms to take full advantage of it! That’s
just plain ridiculous IMO.

----- Original Message ----
From: Tres Walsh <tres.walsh at gmail.com>
Subject: Re: [SDL] SDL in Mercurial!

Oh awesome!

-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] On Behalf Of Ryan C. Gordon
Sent: Friday, February 26, 2010 7:50 PM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL in Mercurial!

This is my test attempt at converting the SDL Subversion repository
to

Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to
replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named
branch.

All revision history in the Subversion repo (back to 1.2.0) is in the
Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk
this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of
bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve
    read a

lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop
    fearing

branching. Mercurial works best when you have a bunch of little
ad-hoc

branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the summary.

  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you
    start using things that Subversion can’t do (bisect, record, shelve,
    rollback, queues, etc), you’re going to find yourself annoyed when
    you

have to work with a Subversion repository and can’t use these extra
features.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I am skeptical about this as well, what are the benefit of a mercurial repo?
Yeah, disk space savings are nice and dandy but not really "productive and
killer feature"
One of the issues with opensource is that it moves, floats, converts files
too often;
imho you should invest the time for building the hg repo to fix bugs and
follow the feature request of the roadmap :slight_smile:

i have one request though: if you do the switch please move every sdl
project to hg, i don’t want to have partial version checking in hg and
partial in svn
bye
VittorioOn Sat, Feb 27, 2010 at 8:39 AM, Paulo Pinto wrote:

I don’t want to dismiss it, I was just pointing out what are the real
reasons to change the SCM
in use.

SDL already changed from CVS to SVN, and Subversion has lots of nice
features over CVS that
are really worth the upgrade, like the ability to rename directories.

Now I was just being sceptic about the gains. Do the majority of the SDL
contributors face daily
issues that would be solved by moving to Mercurial or it is a solution in
search for a problem?

If in 2 years time there is the new XYZ source control will it move again?

As I said, I hardly contribute any real code to SDL so my voice doesn’t
really count here, but I fail
to see the beneficts. Maybe I am too old and have seen this type of
scenario too many times already.


Paulo

On Sat, Feb 27, 2010 at 8:00 AM, Steven Noonan wrote:

I’ve seen projects convert from SVN to Git and see huge increases in
the amount of contributions, largely because of the distributed nature
of the revision control system. With Subversion, the "commit access"
thing is probably more of a pain than most people realize.
Contributors have to do all sorts of painful things to make patches
work with newer revisions, and it gets messy really fast. This really
discourages contribution. Whereas, with something like Mercurial or
Git, you can very easily rebase your work on top of the latest code.
And being able to just “pull” changes into a repository is a huge help
for maintainers as well.

If you want to see a “for instance” of Git helping a project’s
productivity, just take a look at Dungeon Crawl Stone Soup. We
switched from SVN to Git in about September or October, and we’ve been
very pleasantly surprised with the development pace and number of
contributions.

I would not so quickly dismiss a move to Mercurial.

  • Steven

On Fri, Feb 26, 2010 at 10:48 PM, Paulo Pinto wrote:

I have to agree with Mason here.

Being an IT consultant in the real world, and having spent half of my
working years
as SCM/Build manager, I fail to see the advantage here as well.

I hardly contribute any code to SDL, so my voice is worth zero on this
issue, but this looks
like all those real life cases I have witness, where a company changed
their
complete build
infrastructure just because one of their managers decided to change to
the
flavour of the month.

So what are the real benefits Mercurial will bring to SDL developers,
besides some new cool
features, that you might use?

How will be the expected productivity gains?


Paulo

On Sat, Feb 27, 2010 at 5:39 AM, Mason Wheeler wrote:

Not awesome. If it ain’t broke, don’t fix it, and the SVN server isn’t
broke. It’s not that we “fear branching,” it’s that we don’t really
need

the added features that Mercurial brings to the table, and it’s not
worth all the extra hassle of reimplementing a working system to get
functionality that SDL’s development has never needed, and then
having to adapt to new paradigms to take full advantage of it! That’s
just plain ridiculous IMO.

----- Original Message ----
From: Tres Walsh <tres.walsh at gmail.com>
Subject: Re: [SDL] SDL in Mercurial!

Oh awesome!

-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] On Behalf Of Ryan C. Gordon
Sent: Friday, February 26, 2010 7:50 PM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL in Mercurial!

This is my test attempt at converting the SDL Subversion repository
to

Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to
replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named
branch.

All revision history in the Subversion repo (back to 1.2.0) is in
the

Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much
disk

this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of
bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve
    read a

lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop
    fearing

branching. Mercurial works best when you have a bunch of little
ad-hoc

branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the
    summary.
  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once
    you

start using things that Subversion can’t do (bisect, record, shelve,
rollback, queues, etc), you’re going to find yourself annoyed when
you

have to work with a Subversion repository and can’t use these extra
features.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If it makes anything easier for Ryan, Sam, and the others, then it’s worth
it.

Jonny DOn Sat, Feb 27, 2010 at 10:15 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:

I am skeptical about this as well, what are the benefit of a mercurial
repo?
Yeah, disk space savings are nice and dandy but not really "productive and
killer feature"
One of the issues with opensource is that it moves, floats, converts files
too often;
imho you should invest the time for building the hg repo to fix bugs and
follow the feature request of the roadmap :slight_smile:

i have one request though: if you do the switch please move every sdl
project to hg, i don’t want to have partial version checking in hg and
partial in svn
bye
Vittorio

On Sat, Feb 27, 2010 at 8:39 AM, Paulo Pinto wrote:

I don’t want to dismiss it, I was just pointing out what are the real
reasons to change the SCM
in use.

SDL already changed from CVS to SVN, and Subversion has lots of nice
features over CVS that
are really worth the upgrade, like the ability to rename directories.

Now I was just being sceptic about the gains. Do the majority of the SDL
contributors face daily
issues that would be solved by moving to Mercurial or it is a solution in
search for a problem?

If in 2 years time there is the new XYZ source control will it move again?

As I said, I hardly contribute any real code to SDL so my voice doesn’t
really count here, but I fail
to see the beneficts. Maybe I am too old and have seen this type of
scenario too many times already.


Paulo

On Sat, Feb 27, 2010 at 8:00 AM, Steven Noonan wrote:

I’ve seen projects convert from SVN to Git and see huge increases in
the amount of contributions, largely because of the distributed nature
of the revision control system. With Subversion, the "commit access"
thing is probably more of a pain than most people realize.
Contributors have to do all sorts of painful things to make patches
work with newer revisions, and it gets messy really fast. This really
discourages contribution. Whereas, with something like Mercurial or
Git, you can very easily rebase your work on top of the latest code.
And being able to just “pull” changes into a repository is a huge help
for maintainers as well.

If you want to see a “for instance” of Git helping a project’s
productivity, just take a look at Dungeon Crawl Stone Soup. We
switched from SVN to Git in about September or October, and we’ve been
very pleasantly surprised with the development pace and number of
contributions.

I would not so quickly dismiss a move to Mercurial.

  • Steven

On Fri, Feb 26, 2010 at 10:48 PM, Paulo Pinto wrote:

I have to agree with Mason here.

Being an IT consultant in the real world, and having spent half of my
working years
as SCM/Build manager, I fail to see the advantage here as well.

I hardly contribute any code to SDL, so my voice is worth zero on this
issue, but this looks
like all those real life cases I have witness, where a company changed
their
complete build
infrastructure just because one of their managers decided to change to
the
flavour of the month.

So what are the real benefits Mercurial will bring to SDL developers,
besides some new cool
features, that you might use?

How will be the expected productivity gains?


Paulo

On Sat, Feb 27, 2010 at 5:39 AM, Mason Wheeler <masonwheeler at yahoo.com wrote:

Not awesome. If it ain’t broke, don’t fix it, and the SVN server
isn’t

broke. It’s not that we “fear branching,” it’s that we don’t really
need

the added features that Mercurial brings to the table, and it’s not
worth all the extra hassle of reimplementing a working system to get
functionality that SDL’s development has never needed, and then
having to adapt to new paradigms to take full advantage of it! That’s
just plain ridiculous IMO.

----- Original Message ----
From: Tres Walsh <tres.walsh at gmail.com>
Subject: Re: [SDL] SDL in Mercurial!

Oh awesome!

-----Original Message-----
From: sdl-bounces at lists.libsdl.org [mailto:sdl-
bounces at lists.libsdl.org] On Behalf Of Ryan C. Gordon
Sent: Friday, February 26, 2010 7:50 PM
To: sdl at lists.libsdl.org
Subject: [SDL] SDL in Mercurial!

This is my test attempt at converting the SDL Subversion repository
to

Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt
again

while I play around. Eventually, this will move to libsdl.org to
replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent
a

great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos.
This

repo has the 1.3 branch as the default, and SDL-1.2 as a named
branch.

All revision history in the Subversion repo (back to 1.2.0) is in
the

Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much
disk

this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of
bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it’s not too bad, then, especially when you consider that the
svn

checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve
    read a

lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop
    fearing

branching. Mercurial works best when you have a bunch of little
ad-hoc

branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the
    summary.
  • More or less, most commands work like Subversion’s, and there is
    a

TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once
you

start using things that Subversion can’t do (bisect, record,
shelve,

rollback, queues, etc), you’re going to find yourself annoyed when
you

have to work with a Subversion repository and can’t use these extra
features.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hello,

At risk of feeding the flames…

I don’t want to dismiss it, I was just pointing out what are the real
reasons to change the SCM
in use.

SDL already changed from CVS to SVN, and Subversion has lots of nice
features over CVS that
are really worth the upgrade, like the ability to rename directories.

CVS and SVN share the same development model. From a development point
of view there isn’t much change nor gain in that switch. You only have
fancier software that is virtually the same in function.

Now I was just being sceptic about the gains. Do the majority of the SDL
contributors face daily
issues that would be solved by moving to Mercurial or it is a solution in
search for a problem?

It’s a different development model that allows much faster changes,
testing, experimentation and development. You can do changes offline,
branch all the time, etc… It’s much more flexible.

If in 2 years time there is the new XYZ source control will it move again?

Well SVN -> HG is mainly done for going from a centralized development
model to a decentralized development model. CVS and SVN are both
centralized as I mentioned before and very inflexible. Moving to a
decentralized model will help development in many aspects.

Personally ever since I’ve started using GIT all the time I just can’t
stand SVN much. It’s just painful to use. The branching is awful, you
can’t do offline commits and end up creating horribly large patches if
committing against master (to try not to have broken repo ever). Not to
mention that if you are doing small commits and someone else does a
commit more or less where you are working you risk collisions which will
mess up both of the developers.

EdgarOn 2010?02?27? 08:39, Paulo Pinto wrote:

Hello,

Without wanting to call a flame war, I’m curious as to why you’ve chosen
Mercurial over other decentralized version control systems like say GIT
or Bazaar.

Anyway, it’s a great move that will definitely benefit SDL a lot. Hurrah!

EdgarOn 2010?02?27? 04:49, Ryan C. Gordon wrote:

This is my test attempt at converting the SDL Subversion repository to
Mercurial.

http://hg.icculus.org/icculus/SDL/

Feel free to clone, but this repo may be destroyed and rebuilt again
while I play around. Eventually, this will move to libsdl.org to replace
the Subversion repository.

This is just SDL; I have filtered out the other projects and spent a
great deal of time hand-editing the Subversion dump to clean up the
revision history, and will be packaging them in separate repos. This
repo has the 1.3 branch as the default, and SDL-1.2 as a named branch.
All revision history in the Subversion repo (back to 1.2.0) is in the
Mercurial repo.

Upon cloning this repo, I was a little horrified to see how much disk
this eats:

$ du -hs SDL-hg
100M SDL-hg

One hundred megabytes!

This is worth knowing though: that seems like a big collection of bytes,
but that’s a working copy plus every change we made to SDL, ever.

For comparison, here’s a fresh checkout of the trunk and
branches/SDL-1.2 from Subversion:

$ du -chs SDL SDL-1.2
50M SDL
37M SDL-1.2
86M total

So it’s not too bad, then, especially when you consider that the svn
checkout didn’t have any of the GSoC (etc) branches (or any of the
revision history at all).

Here’s all you really need to know about Mercurial.

  • The best quick-start tutorial I’ve read is Joel Spolsky’s new
    hginit.com. You should read it. It’s interesting and funny. I’ve read a
    lot of quick-start tutorials, and no other does it as well.

  • The important thing to know, as a subversion user, is to stop fearing
    branching. Mercurial works best when you have a bunch of little ad-hoc
    branches weaving around each other.

  • When committing new changes, keep the first sentence of the log
    comment short and on a line by itself. It’ll be used for the summary.

  • More or less, most commands work like Subversion’s, and there is a
    TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you
    start using things that Subversion can’t do (bisect, record, shelve,
    rollback, queues, etc), you’re going to find yourself annoyed when you
    have to work with a Subversion repository and can’t use these extra
    features.

Comments and questions welcome.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I was skeptical of the transition, too, and I’m a pretty strong
proponent of starting any new project on Git or Mercurial or Bazaar.

But then I remembered how controversial SDL’s new licensing ambitions
(via Galaxy Gameworks) are. I think it might be a good thing for the
community if it’s easier to work on SDL as a community without needing
to send one’s improvements “upstream” if that would be incompatible
and/or not rewarding enough for them to ordinarily do that. Moving to
Mercurial will make that much easier.On Sat, Feb 27, 2010 at 10:15 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:

I am skeptical about this as well, what are the benefit of a mercurial repo?


http://codebad.com/

If in 2 years time there is the new XYZ source control will it move again?

Yes, if it offers benefits equivalent to what Subversion brought over
CVS, and what Mercurial brings over Subversion.

(Fwiw, we converted to Subversion on April 26th, 2010. Almost 4 years
ago. Also fwiw: I know that because I could type “CVS” into the search
field in the Mercurial web interface. :slight_smile: )

–ryan.

How will be the expected productivity gains?

Here are my immediate thoughts:

I’m on airplanes for about 16 hours this upcoming week, and then will be
sitting in hotel rooms that may not have internet connections after
that. It was awesome when we switched to Subversion from CVS, because I
could diff and revert without a network connection. But I couldn’t
commit. So I would spend time when I got home splitting all the work
into meaningful pieces. The alternative was one massive commit with
"worked on a bunch of stuff" as the log message. If two fixes
overlapped, it was even more effort to split up the patches. With
Mercurial, I just commit like I always would, and when I get to the
Internet, “hg push” will send it on to libsdl.org.

Bug hunting, airplane or not: you can’t bisect with Subversion
(basically, you take all the revisions that could be buggy, try the one
in the middle. Works? Try the newer half of those revisions. Doesn’t?
Try the older half. Keep halving until you find the specific patch that
caused the bug). This only works because all the revisions are on your
hard drive already. Likewise for things like blame and switching between
branches.

I work on several machines. Lots of times I’ll do Mac work on my Linux
workstation, since it has a big monitor, and then move the changes over
to the Macbook with the smaller screen. Now instead of generating
patches and copying them to the other computer, I just commit them on
the Linux box and pull from that clone of the repository. The equivalent
in Subversion is to commit code that might not even compile to
libsdl.org (and everyone else, too). Here, I’m just efficiently pushing
it around my LAN, and once I get it all working, I do one push to
libsdl.org.

Even with universal internet access: we don’t give out Subversion
logins. Now someone can just publish their own branch anywhere on the
internet, so we can see their work and pick and choose from it instead
of making them roll patches. Bitbucket (a Mercurial-flavored GitHub
thing) makes it easy for anyone to throw up their own fork of the
repository and publish their changes without having to own a public server.

If someone in a third world country on a dial up connection takes the
time to clone the repository once, everyone in the area can clone from
him instead of a server in California. Even if they just pass around a
USB stick or CD-R. Once they get the data, they’re all individual,
complete, and functional source repositories.

If libsdl.org’s hard drive catches fire, EVERYONE has a complete backup
of the repository.

If Sam decides he doesn’t want to work on SDL any more, anyone can take
up the torch and have a complete history of the project to work from,
instead of the fork starting from whatever happened to be the last thing
he checked out.

Also: the tools are so much better. Even stupid things like being able
to enable the pager extension, so “hg diff” automatically pushes through
"less" to display changes. Or that the webview is built in (and you can
use it on your own system, not just as a cgi-bin set up on
svn.libsdl.org) Or that you can have extensions at all.

There aren’t tons of .svn directories everywhere (just one .hg at the
top of the tree). You don’t have to go to the top of the tree to do
normal things (diff and commit and such only function on the current
directory and subtrees in subversion).

The end user won’t see much significant difference. I assume most people
get SDL from a tarball, or .deb, or .rpm. Those that get it from
revision control still just pull changes with a single command. But for
them, the “commit” command will now work, too. :slight_smile:

–ryan.

Without wanting to call a flame war, I’m curious as to why you’ve chosen
Mercurial over other decentralized version control systems like say GIT
or Bazaar.

(Really, this is the question I expected, not “why move from Subversion?”)

I considered Mercurial and Git. I didn’t even look at bzr, because it
seems like no one uses it but Ubuntu (which is no small user, of
course). For hosting on icculus.org, I got lots of requests for git and
hg, but none for bzr.

Also, I’ve been using fossil to commit some changes to the SQLite
project this past week, but it’s not ready for heavy, general-purpose
use (although I do wish Mercurial would steal the handful of new and
very good ideas fossil brings to the table).

These are my primary reasons for choosing Hg over Git:

  • Mercurial works better on Windows at the moment. Git used to need
    Cygwin, and the msysgit project doesn’t seem that active. Also, I’ve
    seen a few too many comments from the Git developers that suggest they
    aren’t at all concerned about being hostile to users on Mac OS X and
    Windows. As git’s original purpose is to help the Linux kernel
    developers, I guess that’s not surprising, and if SDL wasn’t so
    concerned with portability, it wouldn’t be a big deal. Fwiw, git seems
    to be largely interested in Unix, but Mercurial does need Python to
    run, so we’re probably going to have problems with obscure systems that
    worked with Subversion. But the ones we really care about: Windows,
    Linux, and Mac OS X? Mercurial is sweet.

  • I personally find Mercurial to be a little easier to use. I think it’s
    a little more welcoming to people migrating from Subversion, too. I
    think that git’s index is a little scary to new users (indeed, Mercurial
    Queues are probably moreso, but they’re optional).

  • All my projects were moved from Subversion to Mercurial many months
    ago, so I have personal experience with it. This is both easier for me
    (of course), and better that I can help other people with questions
    during the transition, where I wouldn’t be so helpful with git.

  • Awhile ago, I made a comment that I liked Mercurial better, but git
    would probably win the public’s mindshare, with x.org and some other
    major players migrating to it. Then several major projects (Python,
    Mozilla, etc) chose Mercurial over git, bitbucket showed up, and Fog
    Creek’s new Kiln product really seem to be generating excitement for
    Mercurial. There is something to be said for using the popular tech,
    since it’s more likely to get improvements. One of the many problems
    with CVS is that no one was really working on it.

That being said, ultimately this is a personal choice that I’m
inflicting on everyone else. Git and Mercurial basically support all the
same features, and mostly have identical workflows. Any given
organization could probably be very happy with either, and both are a
quantum leap over Subversion. I could have very easily gone the other
way and written up a similar email about why I didn’t choose Mercurial.

–ryan.