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.

Deficiencies of our current version control
Current mediawiki/trunk/ is a huge pile of different projects, some of them outdated, some of them are nobody remebers what for. Reorganisation is long overdue.

.... needs moar ....

Centralised vs. distributed
This discusses only our situation, there is plenty of general information on this matter elsewhere.

Requirements

 * 1) Must make things easier, not nore complex.
 * 2) If we decide to split extensions to different repositories, there must be a sane way to include them all into /extensions and update automatically, just as we currently do it with symlinking.

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. See also Comparison of revision control software and Comparison of Bzr/Git/Hg.

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.

Pros

 * 1) User friendly interface, basic functionality is easy to use. Easy to learn, good documentation.
 * 2) Repository design is safe: append-only guarantees history invulnerability; compressed repository storage is efficient
 * 3) Fast (git is faster by half an angström)
 * 4) Permissions are good customisable
 * 5) Easy to extend with python knowledge (or this is a con for you php people out there? :))
 * 6) Cross-platform, available on most systems; repos are portable too.
 * 7) Built-in repository conversion from most SCMs out there

Cons

 * 1) TortoiseHG is pretty fugly if compared to fully native TortoiseSVN and TortoiseGit.
 * 2) No native gui (but many general guis support it, and most people are find with command line)

Pros

 * 1) Allows mixing with SVN: comitting to a bzr master is synchronized to SVN and vice versa. (In theory, not tested)
 * 2) Told to have great merging capabilities

Cons

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