# HG changeset patch # User Bryan O'Sullivan # Date 1179261797 25200 # Node ID 680b7b055aa780216b05177b883bfaa47cb45fc0 # Parent 0ca9045035f76545bd986ffea9b364c9fec7a0aa Brief comparisons with other tools. diff -r 0ca9045035f7 -r 680b7b055aa7 en/intro.tex --- a/en/intro.tex Mon May 14 15:22:32 2007 -0700 +++ b/en/intro.tex Tue May 15 13:43:17 2007 -0700 @@ -320,6 +320,157 @@ \section{Why choose Mercurial?} +Mercurial has a unique set of properties that make it a particularly +good choice as a revision control system. +\begin{itemize} +\item It is easy to learn and use. +\item It is lightweight. +\item It scales excellently. +\item It is easy to customise. +\end{itemize} + +If you are at all familiar with revision control systems, you should +be able to get up and running with Mercurial in less than five +minutes. Even if not, it will take no more than a few minutes +longer. Mercurial's command and feature sets are generally uniform +and consistent, so you can keep track of a few general rules instead +of a host of exceptions. + +On a small project, you can start working with Mercurial in moments. +Creating new changes and branches; transferring changes around +(whether locally or over a network); and history and status operations +are all fast. Mercurial attempts to stay nimble and largely out of +your way by combining low cognitive overhead with blazingly fast +operations. + +The usefulness of Mercurial is not limited to small projects: it is +used by projects with hundreds to thousands of contributors, each +containing tens of thousands of files and hundreds of megabytes of +source code. + +If the core functionality of Mercurial is not enough for you, it's +easy to build on. Mercurial is well suited to scripting tasks, and +its clean internals and implementation in Python make it easy to add +features in the form of extensions. There are a number of popular and +useful extensions already available, ranging from helping to identify +bugs to improving performance. + +\section{Mercurial compared with other tools} + +Before you read on, please understand that this section necessarily +reflects my own experiences, interests, and (dare I say it) biases. I +have used every one of the revision control tools listed below, in +most cases for several years at a time. + +\subsection{Subversion} + +Subversion is a popular revision control tool, developed to replace +CVS. It has a centralised client/server architecture. + +Subversion and Mercurial have similarly named commands for performing +the same operations, so it is easy for a person who is familiar with +one to learn to use the other. Both tools are portable to all popular +operating systems. + +Mercurial has a substantial performance advantage over Subversion on +every revision control operation I have benchmarked. I have measured +its advantage as ranging from a factor of two to a factor of six when +compared with Subversion~1.4.3's \emph{ra\_local} file store, which is +the fastest access method available). In more realistic deployments +involving a network-based store, Subversion will be at a substantially +larger disadvantage. + +Additionally, Subversion incurs a substantial storage overhead to +avoid network transactions for a few common operations, such as +finding modified files (\texttt{status}) and displaying modifications +against the current revision (\texttt{diff}). A Subversion working +copy is, as a result, often approximately the same size as, or larger +than, a Mercurial repository and working directory, even though the +Mercurial repository contains a complete history of the project. + +Subversion does not have a history-aware merge capability, forcing its +users to know exactly which revisions to merge between branches. This +shortcoming is scheduled to be addressed in version 1.5. + +Subversion is currently more widely supported by +revision-control-aware third party tools than is Mercurial, although +this gap is closing. Like Mercurial, Subversion has an excellent user +manual. + +Several tools exist to accurately and completely import revision +history from a Subversion repository into a Mercurial repository, +making the transition from the older tool relatively painless. + +\subsection{Git} + +Git is a distributed revision control tool that was developed for +managing the Linux kernel source tree. Like Mercurial, its early +design was somewhat influenced by Monotone. + +Git has an overwhelming command set, with version~1.5.0 providing~139 +individual commands. It has a reputation for being difficult to +learn. It does not have a user manual, only documentation for +individual commands. + +In terms of performance, git is extremely fast. There are several +common cases in which it is faster than Mercurial, at least on Linux. +However, its performance on (and general support for) Windows is, at +the time of writing, far behind that of Mercurial. + +While a Mercurial repository needs no maintenance, a Git repository +requires frequent manual ``repacks'' of its metadata. Without these, +performance degrades, while space usage grows rapidly. A server that +contains many Git repositories that are not rigorously and frequently +repacked will become heavily disk-bound during backups, and there have +been instances of daily backups taking far longer than~24 hours as a +result. A freshly packed Git repository is slightly smaller than a +Mercurial repository, but an unpacked repository is several orders of +magnitude larger. + +The core of Git is written in C. Many Git commands are implemented as +shell or Perl scripts, and the quality of these scripts varies widely. +I have encountered a number of instances where scripts charged along +blindly in the presence of errors that should have been fatal. + +\subsection{CVS} + +CVS is probably the most widely used revision control tool in the +world. Due to its age and internal untidiness, it has been +essentially unmaintained for many years. + +It has a centralised client/server architecture. It does not group +related file changes into atomic commits, making it easy for people to +``break the build''. It has a muddled and incoherent notion of tags +and branches that I will not attempt to even describe. It does not +support renaming of files or directories well, making it easy to +corrupt a repository. It has almost no internal consistency checking +capabilities, so it is usually not even possible to tell whether or +how a repository is corrupt. I would not recommend CVS for any +project, existing or new. + +Mercurial can import CVS revision history. However, there are a few +caveats that apply; these are true of every other revision control +tool's CVS importer, too. Due to CVS's lack of atomic changes and +unversioned filesystem hierarchy, it is not possible to reconstruct +CVS history completely accurately; some guesswork is involved, and +renames will usually not show up. Because a lot of advanced CVS +administration has to be done by hand and is hence error-prone, it's +common for CVS importers to run into multiple problems with corrupted +repositories (completely bogus revision timestamps and files that have +remained locked for over a decade are just two of the less interesting +problems I can recall from personal experience). + +\subsection{Commercial tools} + +Perforce has a centralised client/server architecture, with no +client-side caching of any data. Unlike modern revision control +tools, Perforce requires that a user run a command to inform the +server about every file they intend to edit. + +The performance of Perforce is quite good for small teams, but it +falls off rapidly as the number of users grows beyond a few dozen. +Modestly large Perforce installations require the deployment of +proxies to cope with the load their users generate. %%% Local Variables: %%% mode: latex