Source control considerations

This page contains some thoughts related to MediaWiki's possible migration to a different source/version control system. Currently, there is no such plans, but such a possibility is unofficially discussed pretty often.

Comparison
This section covers possible candidates along with our current VCS, Subversion. Because migration to a client-server VCS system seems completely unlikely, only distributed systems are taken into account. Same applies to less popular DVCSes. Sorry, Darcs and Monotone guys.

All of the current candidates are mature, have sufficient developer communities and are supported by enough free open-source projects hosters.

Subversion
Subversion was created in 1999 specifically as a replacement for CVS. This resulted in a project that although fixed many of CVS's flaws, didn't address its client-server nature.

Pros

 * 1) Most popular source control system.
 * 2) Simple.
 * 3) Lots of GUI clients.
 * 4) TortoiseSVN especially rocks.
 * 5) Mature and stable API with bindings for virtually every programming language.

Cons

 * 1) Requires a network connection for most operations.
 * 2) Due to the above, slow in many cases. Even worse, can be über-slow for blames on files with long history.
 * 3) Doesn't have some functions DVCS users are used to, such as bisect or stash.
 * 4) Greater load on server.
 * 5) Inconvenient .svn directories everywere.

Pros

 * 1) Fast. Generally, the fastest DVCS around.
 * 2) Surprisingly, has a good GUI client for Windows, TortoiseGit.
 * 3) Lots of features, though sometimes even too many of them, making learning harder.

Cons

 * 1) Lots of annoying Git/Linux fanboys screaming "hell yeah!" but having no idea what the hell they're talking about.
 * 2) Has problems with cross-platformness. Users can use either Cygwin, which is a horrible monster, or Msysgit which patches original Git sources. The latter has no git-daemon, and both have problems with localised filenames (not a problem for current MediaWiki codebase, but still). Performance on Windows is noticeably worse than on POSIX.
 * 3) Git-gui simply sucks. Those who disagree are advised to try using TortoiseSVN for a couple weeks, abstracting themselves from SVN deficiencies.
 * 4) Licensed under the over-restrictive GPL, which makes creation of bindings for different programming languages and IDE intergation problematic. Spawning a process and parsing its stdout really sucks if compared to an API.
 * 5) Has problems with huge code trees, developers usually advice to break things to smaller repositories, which could be inconvenient.

Cons

 * 1) TortoiseHG is pretty fugly if compared to fully native TortoiseSVN and TortoiseGit.

Cons

 * 1) Widely considered the slowest DVCS around, though its developers advertise huge improvements in this field.