igor@403: \chapter{Introducción}
igor@402: \label{chap:intro}
igor@402: 
igor@403: \section{Acerca del control de revisiones}
igor@403: 
igor@403: El control de revisiones es el proceso de administrar diferentes
igor@403: versiones de una pieza de información. En su forma más simple es algo
igor@403: que la mayoría de gente hace a mano: cada vez que usted modifica un
igor@403: fichero, lo graba con un nuevo nombre que contiene un número, el
igor@403: siguiente mayor que el anterior.
igor@403: 
igor@403: Administrar manualmente muchas versiones de un fichero es una tarea
igor@403: propensa a errores, a pesar de que hace bastante tiempo hay
igor@403: herramientas que ayudan en este proceso.  Las primeras herramientas
igor@403: para automatizar el control de revisiones fueron pensadas para que un
igor@403: usuario administrara un solo fichero.  En las décadas pasadas, el
igor@403: alcance de las herramientas de control de revisiones ha ido aumentando
igor@403: considerablemente; ahora manejan muchos archivos y facilitan el
igor@403: trabajo en conjunto de varias personas. Las mejores herramientas de
igor@403: control de revisiones de la actualidad no tienen problema con miles de
igor@403: personas trabajando en proyectos que consisten de decenas de miles de
igor@403: ficheros.
igor@403: 
igor@403: \subsection{¿Por qué usar control de revisiones?}
igor@403: 
igor@403: Hay muchas razones por las cuales usted o su equipo desearía usar una
igor@403: herramienta automática de control de revisiones para un proyecto.
igor@402: \begin{itemize}
igor@403: \item Contar con la historia y la evolución de su proyecto, para
igor@403:   evitar hacer la tarea manualmente. Por cada cambio tendrá una
igor@403:   bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
igor@403:   \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
igor@403: \item Cuando trabaja con más personas, los programas de control de
igor@403:   revisiones facilitan la colaboración.  Por ejemplo, cuando varias
igor@403:   personas de forma casi simultanea pueden hacer cambios
igor@403:   incompatibles, el programa le ayudará a identificar y resolver tales
igor@403:   conflictos.
igor@403: \item Puede ayudarle a recuperarse de equivocaciones. Si aplica un
igor@403:   cambio que posteriormente se evidencia como un error, puede
igor@403:   revertirlo a una versión previa a uno o muchos ficheros. De hecho,
igor@403:   una herramienta \emph{realmente} buena, incluso puede ayudarle
igor@403:   efectivamente a darse cuenta exactamente cuándo se introdujo el
igor@403:   error( para más detalles ver la sección~\ref{sec:undo:bisect}).
igor@403: \item Le permitirá trabajar simultáneamente, y manejar las diferencias
igor@403:   entre múltiples versiones de su proyecto.
igor@402: \end{itemize}
igor@403: La mayoría de estas razones son igualmente validas ---por lo menos en
igor@403: teoría--- así esté trabajando en un proyecto solo, o con mucha gente.
igor@403: 
igor@403: Algo fundamental acerca de lo práctico de un sistema de control de
igor@403: revisiones en estas dos escalas (``un hacker solo'' y ``un equipo
igor@403: gigantesco'') es cómo se comparan los \emph{beneficios} con los
igor@403: \emph{costos}.  Una herramienta de control de revisiones que sea
igor@403: difícil de entender o usar impondrá un costo alto.
igor@403: 
igor@403: Un proyecto de quinientas personas es muy propenso a colapsar
igor@403: solamente con su peso inmediatamente sin una herramienta de control de
igor@403: versiones y un proceso. En este caso, el costo de usar control de
igor@403: revisiones ni siquiera se tiene en cueant, puesto que \emph{sin} él,
igor@403: el fracaso está casi garantizado.
igor@403: 
igor@403: Por otra parte, un ``arreglo rápido'' de una sola persona, excluiría
igor@403: la necesidad de usar una herramienta de control de revisiones, porque
igor@403: casi seguramente, el costo de usar una estaría cerca del costo del
igor@403: proyecto. ¿No es así?
igor@403: 
igor@403: Mercurial solamente soporta \emph{ambas} escalas de de
igor@403: desarrollo. Puede aprender lo básico en pocos minutos, y dado su bajo
igor@403: sobrecosto, puede aplicar el control de revisiones al proyecto más
igor@403: pequeño con facilidad. Su simplicidad significa que no tendrá que
igor@403: preocuparse por conceptos obtusos o secuencias de órdenes compitiendo
igor@403: por espacio mental con lo que sea que \emph{realmente} esté tratando
igor@403: de hacer.  Al mismo tiempo, Mercurial tiene alto desempeño y su
igor@403: naturaleza peer-to-peer le permite escalar indoloramente para manejar
igor@403: grandes proyectos.
igor@403: 
igor@403: Ninguna herramienta de control de revisiones puede salvar un
igor@403: proyecto mal administrado, pero la elección de herramientas puede
igor@403: hacer una gran diferencia en la fluidez con la cual puede trabajar en
igor@403: el proyecto.
igor@403: 
igor@403: \subsection{La cantidad de nombres del control de revisiones}
igor@403: 
igor@403: El control de revisiones es un campo amplio, tan ampli que no hay un
igor@403: acrónimo o nombre único. A continuación presentamos un listado de
igor@403: nombres comunes y acrónimos que se podrían encontrar:
igor@402: \begin{itemize}
igor@403: \item Control de revisiones (RCS)
igor@403: \item Manejo de Configuraciones de Programas(SCM), o administracón de
igor@403:   configuraciones
igor@403: \item Administración de código fuente
igor@403: \item Control de Código Fuente, o Control de Fuentes
igor@403: \item Control de Versiones(VCS)
igor@402: \end{itemize}
igor@403: Algunas personas aducen que estos términos tienen significados
igor@403: diversos, pero en la práctica se sobrelapan tanto que no hay un
igor@403: acuerdo o una forma adecuada de separarlos.
igor@403: 
igor@403: \section{Historia resumida del control de revisiones}
igor@403: 
igor@403: La herramienta de control de revisiones más antigua conocida es SCCS 
igor@403: (Sistema de Control de Código), escrito por Marc Rochkind en Bell
igor@403: Labs, a comienzos de los setentas(1970s).  SCCS operaba sobre archivos
igor@403: individuales, y requería que cada persona que trabajara en el proyecto
igor@403: tuviera acceso a un espacio compartido en un solo sistema.  Solamente
igor@403: una persona podía modificar un archivo en un momento dado; el
igor@403: arbitramiento del acceso a los ficheros se hacía con candados. Era
igor@403: común que la gente pusiera los candados a los ficheros, y que
igor@403: posteriormente olvidara quitarlos, impidiendo que otro pudiera
igor@403: modificar los ficheros en cuestión sin la intervención del
igor@403: administrador.
igor@403: 
igor@403: Walter Tichy desarrolló una alternativa gratutita a SCCS a comienzos
igor@403: de los ochentas(1980s), llamó a su programa RCS(Sistema de Control de
igor@403: Revisiones).  Al igual que SCCS, RCS requería que los desarrolladores
igor@403: trabajaran en un único espacio compartido y colocaran candados a los
igor@403: ficheros para evitar que varias personas los estuvieran modificando
igor@403: simultáneamente.
igor@403: 
igor@403: Después en los ochenta, Dick Grune usó RCS como un bloque de
igor@403: construcción para un conjunto de guiones de línea de comando, que
igor@403: inicialmente llamó cmt, pero que renombró a CVS(Sistema Concurrente de
igor@403: Versiones).  La gran innovación de CVS era que permitía a los
igor@403: desarrolladores trabajar simultáneamente de una forma más o menos
igor@403: independiente en sus propios espacios de trabajo. Los espacios de
igor@403: trabajo personales impedian que los desarrolladores se pisaran las
igor@403: mangueras todo el tiempo, situación común con SCCS y RCS.  Cada
igor@403: desarrollador tenía una copia de todo el fichero del proyecto y podía
igor@403: modificar su copia independientemente, Tenían que fusionar sus
igor@403: ediciones antes de consignar los cambios al repositorio central.
igor@403: 
igor@403: Brian Berliner tomó los scripts originales de Grune y los reescribió
igor@403: en~C, haciéndolos públicos en 1989, código sobre el cual se ha
igor@403: desarrollado la versión moderna de CVS.  CVS posteriormente adquirió
igor@403: la habilidad de operar sobre una conexión de red, dotándolo de una
igor@403: arquitectura, cliente/servidor. La arquitectura de CVS es
igor@403: centralizada; La historia del proyecto está únicamente en el
igor@403: repositorio central.  Los espacios de trabajo de los clientes
igor@403: contienen únicamente copias recientes de las versiones de los
igor@403: ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
igor@403: ha tenido un éxito enorme; Es probablemente el sistema de control de
igor@403: revisiones más extendido del planeta.
igor@402: 
igor@404: A comienzos de los noventa(1990s), Sun MicroSystems desarrollo un
igor@404: temprano sistema distribuido de revisión de controles llamado TeamWare
igor@404: Un espacio de trabajo TeamWare contiene una copia completa de la
igor@404: historia del proyecto. TeamWare no tiene la noción de repositorio
igor@404: central. (CVS se basaba en RCS para el almacenamiento de su historia;
igor@404: TeamWare usaba SCCS.)
igor@404: 
igor@404: A medida que avanzaba la decada de los noventa, se empezño a
igor@404: evidenciar los problemas de CVS.  Alacena cambios simultáneos a muchos
igor@404: archivos de forma individual, en lugar de agruparlos como una
igor@404: operación única y atómica lógicamente.  No maneja bien su jerarquía de
igor@404: ficheros bien; es fácil desordenar un repositorio renombrando ficheros
igor@404: y directorios. Peor aún, su código fuente es difícil de leer y
igor@404: mantener, lo que hace que su ``umbral de dolor'' para arreglar sus
igor@404: problemas arquitecturales algo prohibitivo.
igor@404: 
igor@404: En 2001, Jim Blandy y Karl Fogel, dos desarrolladores que habían
igor@404: trabajado en CVS, comenzaron un proyecto para reemplazarlo con una
igor@404: herramienta con mejor arquitectura y código más limpio.  El resultado,
igor@404: Subversion, no se separó del modelo centralizado cliente/servidor de
igor@404: CVS, pero añadió consignaciones atómicas de varios ficheros, mejor
igor@404: manejo de nombres de espacios, y otras características que lo hacen
igor@404: mejor que CVS. Desde su versión inicial, ha ido creciendo en
igor@404: popularidad.
igor@404: 
igor@404: Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
igor@404: sistema distribuido de control de versiones ambicioso que llamó
igor@404: Monotone. Mientras que Monotone se enfocaba a evitar algunas fallas de
igor@404: diseño de CVS con una arquitectura peer-to-peer, fue mucho más
igor@404: allá(junto con otros proyectos subsecuentes) que unas herramientas de
igor@404: control de revisiones en varios aspectos innovadores. Usa hashes
igor@404: criptográficos como identificadores, y tiene una noción integral de 
igor@404: ``confianza'' para código de diversas fuentes.
igor@404: 
igor@404: Mercurial nació en el 2005.  Algunos de sus aspectos de de diseño
igor@404: fueron influenciados por Monotone, pero Mercurial se enfoca en la
igor@404: facilidad de uso, gran rendimiento y escalabilidad para proyectos muy
igor@404: grandes.
igor@404: 
igor@404: \section{Tendencias en el control de revisiones}
igor@404: 
igor@404: Ha habido varias tendencias en el desarrollo y uso de las herramientas
igor@404: de control de revisiones en las pasadas cuatro décadas, mientras la
igor@404: gente se ha vuelto familiar con las capacidades de sus herramientas
igor@404: así mismo con sus limitaciones.
igor@404: 
igor@404: La primera generación comenzó administrando archivos individuales en
igor@404: computadores por persona. A pesar de que tales herramientas
igor@404: representaron un avance importante frente al control de revisiones
igor@404: manual, su modelo de candados y la limitación a un sólo computador,
igor@404: determinó equipos de trabajo pequeños y acoplados.
igor@404: 
igor@404: La segunda generación dejó atrás esas limitaciones moviéndose a
igor@404: arquitecturas centradas en  redes, y administrando proyectos completos
igor@404: uno a la vez. A medida que los proyectos crecían, nacieron nuevos
igor@404: problemas. Con la necesidad de comunicación frecuente con los
igor@404: servidores, escalar estas máquinas se convirtió en un problema en
igor@404: proyectos realmente grandes. Las redes con poca estabilidad impidieron
igor@404: que usuarios remotos se conectaran al servidor. A medida que los
igor@404: proyecos de código abierto comenzaron a ofrecer acceso de sólo lectura
igor@404: de forma anónima a cualquiera, la gente sin permiso para consignar,
igor@404: vio que no podían usar tales herramientas para interactuar en un
igor@404: proyecto de forma natural, puesto que no podían guardar sus cambios.
igor@404: 
igor@404: La generación actual de herramientas de control de revisiones es de
igor@404: forma natural peer-to-peer.  Todos estos sistemas han eliminado la
igor@404: dependencia de un único servidor central, y han permitido que la
igor@404: gente distribuya sus datos de control de revisiones donde realmente se
igor@404: necesita. La colaboración a través de Internet ha cambiado las
igor@404: limitantes tecnológicas a la cuestión de elección y consenso. Las
igor@404: herramientas modernas pueden operar sin conexión indefinidamenta y
igor@404: autónomamente, necesitando una conexión de red solamente para
igor@404: sincronizar los cambios con otro repositorio.
igor@404: 
igor@404: \section{Algunas ventajas del control distribuido de revisiones}
igor@404: 
igor@404: A pesar de que las herramientas para el control distribuido de
igor@404: revisiones lleva varios años siendo tan robusto y usable como la
igor@404: generación previa de su contraparte, personas que usan herramientas
igor@404: más antiguas no se han percatado de sus ventajas.  Hay gran cantidad
igor@404: de situaciones en las cuales las herramientas distribuidas brillan
igor@404: frente a las centralizadas.
igor@404: 
igor@404: Para un desarrollador individual, las herramientas distribuidas casi
igor@404: siempre son más rápidas que las centralizadas. Por una razón sencilla:
igor@404: Una herramienta centralizada necesita comunicarse por red para las
igor@404: operaciones más usuales, debido a que los metadatos se almacenan en
igor@404: una sola copia en el servidor central. Una herramienta distribuida
igor@404: almacena todos sus metadatos localmente.  Con todo lo demás de la
igor@404: misma forma, comunicarse por red tiene un sobrecosto en una
igor@404: herramienta centralizada. No subestime el valor de una herramienta de
igor@404: respuesta rápida: Usted empleará mucho tiempo interactuando con su
igor@404: programa de control de revisiones.
igor@404: 
igor@404: Las herramientas distribuidas son indiferentes a los caprichos de su
igor@404: infraestructura de servidores, de nuevo, debido a la replicación de
igor@404: metadatos en tantos lugares. Si usa un sistema centralizado y su
igor@404: servidor explota, ojalá los medios físicos de su copia de seguridad
igor@404: sean confiables, y que su última copia sea reciente y además
igor@404: funcione. Con una herramienta distribuida tiene tantas copias de
igor@404: seguridad disponibles como computadores de contribuidores.
igor@404: 
igor@404: La confiabilidad de su red afectará las herramientas distribuidas de
igor@404: una forma mucho menor que las herramientas centralizadas No puede
igor@404: siquiera usar una herramienta centralizada sin conexión de red,
igor@404: excepto con algunas órdenes muy limitadas. Con herramientas
igor@404: distribuidas, si sus conexión cae mientras usted está trabajando,
igor@404: podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
igor@404: comunicarse  con repositorios en otros computadores, algo que es
igor@404: relativamente raro comparado con las operaciones locales. Si tiene
igor@404: colaboradores remotos en su equipo, puede ser significante.
igor@404: 
igor@404: \subsection{Ventajas para proyectos de código abierto}
igor@404: 
igor@404: Si descubre un proyecto de código abierto y decide que desea comenzar
igor@404: a trabajar en él, y ese proyecto usa una herramienta de control
igor@404: distribuido de revisiones, usted es un par con la gente que se
igor@404: considera el ``alma'' del proyecto.  Si ellos publican los
igor@404: repositorios, se puede copiar inmediatamente la historia del proyecto,
igor@404: hacer cambios y guardar su trabajo, usando las mismas herramientas de
igor@404: la misma forma que ellos. En contraste, con una herramienta
igor@404: centralizada, debe usar el programa en un modo ``sólo lectura'' a
igor@404: menos que alguien le otorgue permisos para consignar cambios en el
igor@404: repositorio central. Hasta entonces, no podrá almacenar sus cambios y
igor@404: sus modificaciones locales correrán el riesgo de dañarse cuando trate
igor@404: de actualizar su vista del repositorio.
igor@404: 
igor@404: \subsubsection{Las bifurcaciones(forks) no son un problema}
igor@404: 
igor@404: Se ha mencionado que las herramientas de control distribuido de
igor@404: versiones albergan un riesgo a los proyectos de código abierto, puesto
jerojasro@405: que se vuelve muy sencillo hacer una ``bifurcanción''\ndt{fork.} del
igor@404: desarrollo del proyecto.  Una bifurcación pasa cuando hay diferencias
igor@404: de opinión o actitud entre grupos de desarrolladores que desenvoca en
igor@404: la decisión de la imposibilidad de continuar trabajando juntos. Cada
igor@404: parte toma una copia más o menos completa del código fuente del
igor@404: proyecto y toma su propio rumbo.
igor@404: 
igor@404: En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
igor@404: diferencias. Con un sistema centralizado de control de revisiones, el
igor@404: proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
igor@404: forma muy manual.  Tiene que decidir qué historia de revisiones va a
igor@404: ``win'', e injertar los cambios del otro equipo en el árbol de alguna
igor@404: manera. Con esto usualmente se pierde algo o todo del historial de la
igor@404: revisión de alguna de las partes.
igor@404: 
igor@404: Lo que las herramientas distribuidas hacen con respecto a las
igor@404: bifurcaciones, es que las bifurcaciones son la \emph{única} forma de
igor@404: desarrollar un proyecto. Cada cambio que usted hace es potencialmente
igor@404: un punto de bifurcación. La gran fortaleza de esta aproximación es que
igor@404: las herramientas distribuidas de control de revisiones tiene que ser
igor@404: bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
igor@404: son absolutamente fundamentales: pasan todo el tiempo.
igor@404: 
igor@404: Si todas las porciones de trabajo que todos hacen todo el tiempo, se
igor@404: enmarca en términos de bifurcaciones y fusiones, entonces a aquello a
igor@404: lo que se refiere en el mundo del código abierto a una ``bifurcación''
igor@404: se convierte \emph{puramente} en una cuestión social. Lo que hacen las
igor@404: herramientas distribuidas es \emph{disminuir} la posibilidad de una
igor@404: bifurcación porque:
igor@402: \begin{itemize}
igor@404: \item Eliminan la distinción social que las herramientas centralizadas
igor@404:   imponen: esto entre los miembros (personas con permiso de consignar)
igor@404:   y forasteros(los que no tienen el permiso).
igor@404: \item Facilitan la reconciliación después de una bifurcación social,
igor@404:   porque todo lo que concierne al programa de control de revisiones es
igor@404:   una fusión.
igor@402: \end{itemize}
igor@402: 
igor@404: Algunas personas se resisten a las herramientas distribuidas porque
igor@404: desean mantener control completo sobre sus proyectos, y creen que las
igor@404: herramientas centralizadas les dan tal control. En todo caso, si este
igor@404: es su parecer, y publica sus repositorios de CVS o Subversion, hay
igor@404: muchas herramientas disponibles que pueden obtener la historia
igor@404: completa(A pesar de lo lento) y recrearla en otro sitio que usted no
igor@404: controla. Siendo así un control ilusorio, está impidiendo la fluidez
igor@404: de colaboración frente a quien se sienta impulsado a obtener una copia
igor@404: y hacer una bifurcación con su historia.
igor@402: 
igor@402: \subsection{Advantages for commercial projects}
igor@402: 
igor@402: Many commercial projects are undertaken by teams that are scattered
igor@402: across the globe.  Contributors who are far from a central server will
igor@402: see slower command execution and perhaps less reliability.  Commercial
igor@402: revision control systems attempt to ameliorate these problems with
igor@402: remote-site replication add-ons that are typically expensive to buy
igor@402: and cantankerous to administer.  A distributed system doesn't suffer
igor@402: from these problems in the first place.  Better yet, you can easily
igor@402: set up multiple authoritative servers, say one per site, so that
igor@402: there's no redundant communication between repositories over expensive
igor@402: long-haul network links.
igor@402: 
igor@402: Centralised revision control systems tend to have relatively low
igor@402: scalability.  It's not unusual for an expensive centralised system to
igor@402: fall over under the combined load of just a few dozen concurrent
igor@402: users.  Once again, the typical response tends to be an expensive and
igor@402: clunky replication facility.  Since the load on a central server---if
igor@402: you have one at all---is many times lower with a distributed
igor@402: tool (because all of the data is replicated everywhere), a single
igor@402: cheap server can handle the needs of a much larger team, and
igor@402: replication to balance load becomes a simple matter of scripting.
igor@402: 
igor@402: If you have an employee in the field, troubleshooting a problem at a
igor@402: customer's site, they'll benefit from distributed revision control.
igor@402: The tool will let them generate custom builds, try different fixes in
igor@402: isolation from each other, and search efficiently through history for
igor@402: the sources of bugs and regressions in the customer's environment, all
igor@402: without needing to connect to your company's network.
igor@402: 
igor@402: \section{Why choose Mercurial?}
igor@402: 
igor@402: Mercurial has a unique set of properties that make it a particularly
igor@402: good choice as a revision control system.
igor@402: \begin{itemize}
igor@402: \item It is easy to learn and use.
igor@402: \item It is lightweight.
igor@402: \item It scales excellently.
igor@402: \item It is easy to customise.
igor@402: \end{itemize}
igor@402: 
igor@402: If you are at all familiar with revision control systems, you should
igor@402: be able to get up and running with Mercurial in less than five
igor@402: minutes.  Even if not, it will take no more than a few minutes
igor@402: longer.  Mercurial's command and feature sets are generally uniform
igor@402: and consistent, so you can keep track of a few general rules instead
igor@402: of a host of exceptions.
igor@402: 
igor@402: On a small project, you can start working with Mercurial in moments.
igor@402: Creating new changes and branches; transferring changes around
igor@402: (whether locally or over a network); and history and status operations
igor@402: are all fast.  Mercurial attempts to stay nimble and largely out of
igor@402: your way by combining low cognitive overhead with blazingly fast
igor@402: operations.
igor@402: 
igor@402: The usefulness of Mercurial is not limited to small projects: it is
igor@402: used by projects with hundreds to thousands of contributors, each
igor@402: containing tens of thousands of files and hundreds of megabytes of
igor@402: source code.
igor@402: 
igor@402: If the core functionality of Mercurial is not enough for you, it's
igor@402: easy to build on.  Mercurial is well suited to scripting tasks, and
igor@402: its clean internals and implementation in Python make it easy to add
igor@402: features in the form of extensions.  There are a number of popular and
igor@402: useful extensions already available, ranging from helping to identify
igor@402: bugs to improving performance.
igor@402: 
igor@402: \section{Mercurial compared with other tools}
igor@402: 
igor@402: Before you read on, please understand that this section necessarily
igor@402: reflects my own experiences, interests, and (dare I say it) biases.  I
igor@402: have used every one of the revision control tools listed below, in
igor@402: most cases for several years at a time.
igor@402: 
igor@402: 
igor@402: \subsection{Subversion}
igor@402: 
igor@402: Subversion is a popular revision control tool, developed to replace
igor@402: CVS.  It has a centralised client/server architecture.
igor@402: 
igor@402: Subversion and Mercurial have similarly named commands for performing
igor@402: the same operations, so if you're familiar with one, it is easy to
igor@402: learn to use the other.  Both tools are portable to all popular
igor@402: operating systems.
igor@402: 
igor@402: Prior to version 1.5, Subversion had no useful support for merges.
igor@402: At the time of writing, its merge tracking capability is new, and known to be
igor@402: \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicated
igor@402:   and buggy}.
igor@402: 
igor@402: Mercurial has a substantial performance advantage over Subversion on
igor@402: every revision control operation I have benchmarked.  I have measured
igor@402: its advantage as ranging from a factor of two to a factor of six when
igor@402: compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
igor@402: the fastest access method available.  In more realistic deployments
igor@402: involving a network-based store, Subversion will be at a substantially
igor@402: larger disadvantage.  Because many Subversion commands must talk to
igor@402: the server and Subversion does not have useful replication facilities,
igor@402: server capacity and network bandwidth become bottlenecks for modestly
igor@402: large projects.
igor@402: 
igor@402: Additionally, Subversion incurs substantial storage overhead to avoid
igor@402: network transactions for a few common operations, such as finding
igor@402: modified files (\texttt{status}) and displaying modifications against
igor@402: the current revision (\texttt{diff}).  As a result, a Subversion
igor@402: working copy is often the same size as, or larger than, a Mercurial
igor@402: repository and working directory, even though the Mercurial repository
igor@402: contains a complete history of the project.
igor@402: 
igor@402: Subversion is widely supported by third party tools.  Mercurial
igor@402: currently lags considerably in this area.  This gap is closing,
igor@402: however, and indeed some of Mercurial's GUI tools now outshine their
igor@402: Subversion equivalents.  Like Mercurial, Subversion has an excellent
igor@402: user manual.
igor@402: 
igor@402: Because Subversion doesn't store revision history on the client, it is
igor@402: well suited to managing projects that deal with lots of large, opaque
igor@402: binary files.  If you check in fifty revisions to an incompressible
igor@402: 10MB file, Subversion's client-side space usage stays constant The
igor@402: space used by any distributed SCM will grow rapidly in proportion to
igor@402: the number of revisions, because the differences between each revision
igor@402: are large.
igor@402: 
igor@402: In addition, it's often difficult or, more usually, impossible to
igor@402: merge different versions of a binary file.  Subversion's ability to
igor@402: let a user lock a file, so that they temporarily have the exclusive
igor@402: right to commit changes to it, can be a significant advantage to a
igor@402: project where binary files are widely used.
igor@402: 
igor@402: Mercurial can import revision history from a Subversion repository.
igor@402: It can also export revision history to a Subversion repository.  This
igor@402: makes it easy to ``test the waters'' and use Mercurial and Subversion
igor@402: in parallel before deciding to switch.  History conversion is
igor@402: incremental, so you can perform an initial conversion, then small
igor@402: additional conversions afterwards to bring in new changes.
igor@402: 
igor@402: 
igor@402: \subsection{Git}
igor@402: 
igor@402: Git is a distributed revision control tool that was developed for
igor@402: managing the Linux kernel source tree.  Like Mercurial, its early
igor@402: design was somewhat influenced by Monotone.
igor@402: 
igor@402: Git has a very large command set, with version~1.5.0 providing~139
igor@402: individual commands.  It has something of a reputation for being
igor@402: difficult to learn.  Compared to Git, Mercurial has a strong focus on
igor@402: simplicity.
igor@402: 
igor@402: In terms of performance, Git is extremely fast.  In several cases, it
igor@402: is faster than Mercurial, at least on Linux, while Mercurial performs
igor@402: better on other operations.  However, on Windows, the performance and
igor@402: general level of support that Git provides is, at the time of writing,
igor@402: far behind that of Mercurial.
igor@402: 
igor@402: While a Mercurial repository needs no maintenance, a Git repository
igor@402: requires frequent manual ``repacks'' of its metadata.  Without these,
igor@402: performance degrades, while space usage grows rapidly.  A server that
igor@402: contains many Git repositories that are not rigorously and frequently
igor@402: repacked will become heavily disk-bound during backups, and there have
igor@402: been instances of daily backups taking far longer than~24 hours as a
igor@402: result.  A freshly packed Git repository is slightly smaller than a
igor@402: Mercurial repository, but an unpacked repository is several orders of
igor@402: magnitude larger.
igor@402: 
igor@402: The core of Git is written in C.  Many Git commands are implemented as
igor@402: shell or Perl scripts, and the quality of these scripts varies widely.
igor@402: I have encountered several instances where scripts charged along
igor@402: blindly in the presence of errors that should have been fatal.
igor@402: 
igor@402: Mercurial can import revision history from a Git repository.
igor@402: 
igor@402: 
igor@402: \subsection{CVS}
igor@402: 
igor@402: CVS is probably the most widely used revision control tool in the
igor@402: world.  Due to its age and internal untidiness, it has been only
igor@402: lightly maintained for many years.
igor@402: 
igor@402: It has a centralised client/server architecture.  It does not group
igor@402: related file changes into atomic commits, making it easy for people to
igor@402: ``break the build'': one person can successfully commit part of a
igor@402: change and then be blocked by the need for a merge, causing other
igor@402: people to see only a portion of the work they intended to do.  This
igor@402: also affects how you work with project history.  If you want to see
igor@402: all of the modifications someone made as part of a task, you will need
igor@402: to manually inspect the descriptions and timestamps of the changes
igor@402: made to each file involved (if you even know what those files were).
igor@402: 
igor@402: CVS has a muddled notion of tags and branches that I will not attempt
igor@402: to even describe.  It does not support renaming of files or
igor@402: directories well, making it easy to corrupt a repository.  It has
igor@402: almost no internal consistency checking capabilities, so it is usually
igor@402: not even possible to tell whether or how a repository is corrupt.  I
igor@402: would not recommend CVS for any project, existing or new.
igor@402: 
igor@402: Mercurial can import CVS revision history.  However, there are a few
igor@402: caveats that apply; these are true of every other revision control
igor@402: tool's CVS importer, too.  Due to CVS's lack of atomic changes and
igor@402: unversioned filesystem hierarchy, it is not possible to reconstruct
igor@402: CVS history completely accurately; some guesswork is involved, and
igor@402: renames will usually not show up.  Because a lot of advanced CVS
igor@402: administration has to be done by hand and is hence error-prone, it's
igor@402: common for CVS importers to run into multiple problems with corrupted
igor@402: repositories (completely bogus revision timestamps and files that have
igor@402: remained locked for over a decade are just two of the less interesting
igor@402: problems I can recall from personal experience).
igor@402: 
igor@402: Mercurial can import revision history from a CVS repository.
igor@402: 
igor@402: 
igor@402: \subsection{Commercial tools}
igor@402: 
igor@402: Perforce has a centralised client/server architecture, with no
igor@402: client-side caching of any data.  Unlike modern revision control
igor@402: tools, Perforce requires that a user run a command to inform the
igor@402: server about every file they intend to edit.
igor@402: 
igor@402: The performance of Perforce is quite good for small teams, but it
igor@402: falls off rapidly as the number of users grows beyond a few dozen.
igor@402: Modestly large Perforce installations require the deployment of
igor@402: proxies to cope with the load their users generate.
igor@402: 
igor@402: 
igor@402: \subsection{Choosing a revision control tool}
igor@402: 
igor@402: With the exception of CVS, all of the tools listed above have unique
igor@402: strengths that suit them to particular styles of work.  There is no
igor@402: single revision control tool that is best in all situations.
igor@402: 
igor@402: As an example, Subversion is a good choice for working with frequently
igor@402: edited binary files, due to its centralised nature and support for
igor@402: file locking.
igor@402: 
igor@402: I personally find Mercurial's properties of simplicity, performance,
igor@402: and good merge support to be a compelling combination that has served
igor@402: me well for several years.
igor@402: 
igor@402: 
igor@402: \section{Switching from another tool to Mercurial}
igor@402: 
igor@402: Mercurial is bundled with an extension named \hgext{convert}, which
igor@402: can incrementally import revision history from several other revision
igor@402: control tools.  By ``incremental'', I mean that you can convert all of
igor@402: a project's history to date in one go, then rerun the conversion later
igor@402: to obtain new changes that happened after the initial conversion.
igor@402: 
igor@402: The revision control tools supported by \hgext{convert} are as
igor@402: follows:
igor@402: \begin{itemize}
igor@402: \item Subversion
igor@402: \item CVS
igor@402: \item Git
igor@402: \item Darcs
igor@402: \end{itemize}
igor@402: 
igor@402: In addition, \hgext{convert} can export changes from Mercurial to
igor@402: Subversion.  This makes it possible to try Subversion and Mercurial in
igor@402: parallel before committing to a switchover, without risking the loss
igor@402: of any work.
igor@402: 
igor@402: The \hgxcmd{conver}{convert} command is easy to use.  Simply point it
igor@402: at the path or URL of the source repository, optionally give it the
igor@402: name of the destination repository, and it will start working.  After
igor@402: the initial conversion, just run the same command again to import new
igor@402: changes.
igor@402: 
igor@402: 
igor@402: %%% Local Variables: 
igor@402: %%% mode: latex
igor@402: %%% TeX-master: "00book"
igor@402: %%% End: