view es/intro.tex @ 505:446d1b4b7a71

translated up to section 4.2.1, included

\chapter{Introducción}
\label{chap:intro}

\section{Acerca del control de revisiones}

El control de revisiones es el proceso de administrar diferentes
versiones de una pieza de información. En su forma más simple es algo
que la mayoría de gente hace a mano: cada vez que usted modifica un
fichero, lo graba con un nuevo nombre que contiene un número, el
siguiente mayor que el anterior.

Administrar manualmente muchas versiones de un fichero es una tarea
propensa a errores, a pesar de que hace bastante tiempo hay
herramientas que ayudan en este proceso.  Las primeras herramientas
para automatizar el control de revisiones fueron pensadas para que un
usuario administrara un solo fichero.  En las décadas pasadas, el
alcance de las herramientas de control de revisiones ha ido aumentando
considerablemente; ahora manejan muchos archivos y facilitan el
trabajo en conjunto de varias personas. Las mejores herramientas de
control de revisiones de la actualidad no tienen problema con miles de
personas trabajando en proyectos que consisten de decenas de miles de
ficheros.

\subsection{¿Por qué usar control de revisiones?}

Hay muchas razones por las cuales usted o su equipo desearía usar una
herramienta automática de control de revisiones para un proyecto.
\begin{itemize}
\item Contar con la historia y la evolución de su proyecto, para
  evitar hacer la tarea manualmente. Por cada cambio tendrá una
  bitácora de \emph{quién} lo hizo; \emph{por qué} se hizo;
  \emph{cuándo} se hizo; y de \emph{qué} se trataba el cambio.
\item Cuando trabaja con más personas, los programas de control de
  revisiones facilitan la colaboración.  Por ejemplo, cuando varias
  personas de forma casi simultanea pueden hacer cambios
  incompatibles, el programa le ayudará a identificar y resolver tales
  conflictos.
\item Puede ayudarle a recuperarse de equivocaciones. Si aplica un
  cambio que posteriormente se evidencia como un error, puede
  revertirlo a una versión previa a uno o muchos ficheros. De hecho,
  una herramienta \emph{realmente} buena, incluso puede ayudarle
  efectivamente a darse cuenta exactamente cuándo se introdujo el
  error( para más detalles ver la sección~\ref{sec:undo:bisect}).
\item Le permitirá trabajar simultáneamente, y manejar las diferencias
  entre múltiples versiones de su proyecto.
\end{itemize}
La mayoría de estas razones son igualmente validas ---por lo menos en
teoría--- así esté trabajando en un proyecto solo, o con mucha gente.

Algo fundamental acerca de lo práctico de un sistema de control de
revisiones en estas dos escalas (``un hacker solo'' y ``un equipo
gigantesco'') es cómo se comparan los \emph{beneficios} con los
\emph{costos}.  Una herramienta de control de revisiones que sea
difícil de entender o usar impondrá un costo alto.

Un proyecto de quinientas personas es muy propenso a colapsar
solamente con su peso inmediatamente sin una herramienta de control de
versiones y un proceso. En este caso, el costo de usar control de
revisiones ni siquiera se tiene en cueant, puesto que \emph{sin} él,
el fracaso está casi garantizado.

Por otra parte, un ``arreglo rápido'' de una sola persona, excluiría
la necesidad de usar una herramienta de control de revisiones, porque
casi seguramente, el costo de usar una estaría cerca del costo del
proyecto. ¿No es así?

Mercurial solamente soporta \emph{ambas} escalas de de
desarrollo. Puede aprender lo básico en pocos minutos, y dado su bajo
sobrecosto, puede aplicar el control de revisiones al proyecto más
pequeño con facilidad. Su simplicidad significa que no tendrá que
preocuparse por conceptos obtusos o secuencias de órdenes compitiendo
por espacio mental con lo que sea que \emph{realmente} esté tratando
de hacer.  Al mismo tiempo, Mercurial tiene alto desempeño y su
naturaleza peer-to-peer le permite escalar indoloramente para manejar
grandes proyectos.

Ninguna herramienta de control de revisiones puede salvar un
proyecto mal administrado, pero la elección de herramientas puede
hacer una gran diferencia en la fluidez con la cual puede trabajar en
el proyecto.

\subsection{La cantidad de nombres del control de revisiones}

El control de revisiones es un campo amplio, tan ampli que no hay un
acrónimo o nombre único. A continuación presentamos un listado de
nombres comunes y acrónimos que se podrían encontrar:
\begin{itemize}
\item Control de revisiones (RCS)
\item Manejo de Configuraciones de Programas(SCM), o administracón de
  configuraciones
\item Administración de código fuente
\item Control de Código Fuente, o Control de Fuentes
\item Control de Versiones(VCS)
\end{itemize}
Algunas personas aducen que estos términos tienen significados
diversos, pero en la práctica se sobrelapan tanto que no hay un
acuerdo o una forma adecuada de separarlos.

\section{Historia resumida del control de revisiones}

La herramienta de control de revisiones más antigua conocida es SCCS 
(Sistema de Control de Código), escrito por Marc Rochkind en Bell
Labs, a comienzos de los setentas(1970s).  SCCS operaba sobre archivos
individuales, y requería que cada persona que trabajara en el proyecto
tuviera acceso a un espacio compartido en un solo sistema.  Solamente
una persona podía modificar un archivo en un momento dado; el
arbitramiento del acceso a los ficheros se hacía con candados. Era
común que la gente pusiera los candados a los ficheros, y que
posteriormente olvidara quitarlos, impidiendo que otro pudiera
modificar los ficheros en cuestión sin la intervención del
administrador.

Walter Tichy desarrolló una alternativa gratutita a SCCS a comienzos
de los ochentas(1980s), llamó a su programa RCS(Sistema de Control de
Revisiones).  Al igual que SCCS, RCS requería que los desarrolladores
trabajaran en un único espacio compartido y colocaran candados a los
ficheros para evitar que varias personas los estuvieran modificando
simultáneamente.

Después en los ochenta, Dick Grune usó RCS como un bloque de
construcción para un conjunto de guiones de línea de comando, que
inicialmente llamó cmt, pero que renombró a CVS(Sistema Concurrente de
Versiones).  La gran innovación de CVS era que permitía a los
desarrolladores trabajar simultáneamente de una forma más o menos
independiente en sus propios espacios de trabajo. Los espacios de
trabajo personales impedian que los desarrolladores se pisaran las
mangueras todo el tiempo, situación común con SCCS y RCS.  Cada
desarrollador tenía una copia de todo el fichero del proyecto y podía
modificar su copia independientemente, Tenían que fusionar sus
ediciones antes de consignar los cambios al repositorio central.

Brian Berliner tomó los scripts originales de Grune y los reescribió
en~C, haciéndolos públicos en 1989, código sobre el cual se ha
desarrollado la versión moderna de CVS.  CVS posteriormente adquirió
la habilidad de operar sobre una conexión de red, dotándolo de una
arquitectura, cliente/servidor. La arquitectura de CVS es
centralizada; La historia del proyecto está únicamente en el
repositorio central.  Los espacios de trabajo de los clientes
contienen únicamente copias recientes de las versiones de los
ficheros, y pocos metadatos para indicar dónde está el servidor. CVS
ha tenido un éxito enorme; Es probablemente el sistema de control de
revisiones más extendido del planeta.

A comienzos de los noventa(1990s), Sun MicroSystems desarrollo un
temprano sistema distribuido de revisión de controles llamado TeamWare
Un espacio de trabajo TeamWare contiene una copia completa de la
historia del proyecto. TeamWare no tiene la noción de repositorio
central. (CVS se basaba en RCS para el almacenamiento de su historia;
TeamWare usaba SCCS.)

A medida que avanzaba la decada de los noventa, se empezño a
evidenciar los problemas de CVS.  Alacena cambios simultáneos a muchos
archivos de forma individual, en lugar de agruparlos como una
operación única y atómica lógicamente.  No maneja bien su jerarquía de
ficheros bien; es fácil desordenar un repositorio renombrando ficheros
y directorios. Peor aún, su código fuente es difícil de leer y
mantener, lo que hace que su ``umbral de dolor'' para arreglar sus
problemas arquitecturales algo prohibitivo.

En 2001, Jim Blandy y Karl Fogel, dos desarrolladores que habían
trabajado en CVS, comenzaron un proyecto para reemplazarlo con una
herramienta con mejor arquitectura y código más limpio.  El resultado,
Subversion, no se separó del modelo centralizado cliente/servidor de
CVS, pero añadió consignaciones atómicas de varios ficheros, mejor
manejo de nombres de espacios, y otras características que lo hacen
mejor que CVS. Desde su versión inicial, ha ido creciendo en
popularidad.

Más o menos en forma simultánea Graydon Hoare comenzó a trabajar en un
sistema distribuido de control de versiones ambicioso que llamó
Monotone. Mientras que Monotone se enfocaba a evitar algunas fallas de
diseño de CVS con una arquitectura peer-to-peer, fue mucho más
allá(junto con otros proyectos subsecuentes) que unas herramientas de
control de revisiones en varios aspectos innovadores. Usa hashes
criptográficos como identificadores, y tiene una noción integral de 
``confianza'' para código de diversas fuentes.

Mercurial nació en el 2005.  Algunos de sus aspectos de de diseño
fueron influenciados por Monotone, pero Mercurial se enfoca en la
facilidad de uso, gran rendimiento y escalabilidad para proyectos muy
grandes.

\section{Tendencias en el control de revisiones}

Ha habido varias tendencias en el desarrollo y uso de las herramientas
de control de revisiones en las pasadas cuatro décadas, mientras la
gente se ha vuelto familiar con las capacidades de sus herramientas
así mismo con sus limitaciones.

La primera generación comenzó administrando archivos individuales en
computadores por persona. A pesar de que tales herramientas
representaron un avance importante frente al control de revisiones
manual, su modelo de candados y la limitación a un sólo computador,
determinó equipos de trabajo pequeños y acoplados.

La segunda generación dejó atrás esas limitaciones moviéndose a
arquitecturas centradas en  redes, y administrando proyectos completos
uno a la vez. A medida que los proyectos crecían, nacieron nuevos
problemas. Con la necesidad de comunicación frecuente con los
servidores, escalar estas máquinas se convirtió en un problema en
proyectos realmente grandes. Las redes con poca estabilidad impidieron
que usuarios remotos se conectaran al servidor. A medida que los
proyecos de código abierto comenzaron a ofrecer acceso de sólo lectura
de forma anónima a cualquiera, la gente sin permiso para consignar,
vio que no podían usar tales herramientas para interactuar en un
proyecto de forma natural, puesto que no podían guardar sus cambios.

La generación actual de herramientas de control de revisiones es de
forma natural peer-to-peer.  Todos estos sistemas han eliminado la
dependencia de un único servidor central, y han permitido que la
gente distribuya sus datos de control de revisiones donde realmente se
necesita. La colaboración a través de Internet ha cambiado las
limitantes tecnológicas a la cuestión de elección y consenso. Las
herramientas modernas pueden operar sin conexión indefinidamenta y
autónomamente, necesitando una conexión de red solamente para
sincronizar los cambios con otro repositorio.

\section{Algunas ventajas del control distribuido de revisiones}

A pesar de que las herramientas para el control distribuido de
revisiones lleva varios años siendo tan robusto y usable como la
generación previa de su contraparte, personas que usan herramientas
más antiguas no se han percatado de sus ventajas.  Hay gran cantidad
de situaciones en las cuales las herramientas distribuidas brillan
frente a las centralizadas.

Para un desarrollador individual, las herramientas distribuidas casi
siempre son más rápidas que las centralizadas. Por una razón sencilla:
Una herramienta centralizada necesita comunicarse por red para las
operaciones más usuales, debido a que los metadatos se almacenan en
una sola copia en el servidor central. Una herramienta distribuida
almacena todos sus metadatos localmente.  Con todo lo demás de la
misma forma, comunicarse por red tiene un sobrecosto en una
herramienta centralizada. No subestime el valor de una herramienta de
respuesta rápida: Usted empleará mucho tiempo interactuando con su
programa de control de revisiones.

Las herramientas distribuidas son indiferentes a los caprichos de su
infraestructura de servidores, de nuevo, debido a la replicación de
metadatos en tantos lugares. Si usa un sistema centralizado y su
servidor explota, ojalá los medios físicos de su copia de seguridad
sean confiables, y que su última copia sea reciente y además
funcione. Con una herramienta distribuida tiene tantas copias de
seguridad disponibles como computadores de contribuidores.

La confiabilidad de su red afectará las herramientas distribuidas de
una forma mucho menor que las herramientas centralizadas No puede
siquiera usar una herramienta centralizada sin conexión de red,
excepto con algunas órdenes muy limitadas. Con herramientas
distribuidas, si sus conexión cae mientras usted está trabajando,
podría nisiquiera darse cuenta. Lo único que que no podrá hacer es
comunicarse  con repositorios en otros computadores, algo que es
relativamente raro comparado con las operaciones locales. Si tiene
colaboradores remotos en su equipo, puede ser significante.

\subsection{Ventajas para proyectos de código abierto}

Si descubre un proyecto de código abierto y decide que desea comenzar
a trabajar en él, y ese proyecto usa una herramienta de control
distribuido de revisiones, usted es un par con la gente que se
considera el ``alma'' del proyecto.  Si ellos publican los
repositorios, se puede copiar inmediatamente la historia del proyecto,
hacer cambios y guardar su trabajo, usando las mismas herramientas de
la misma forma que ellos. En contraste, con una herramienta
centralizada, debe usar el programa en un modo ``sólo lectura'' a
menos que alguien le otorgue permisos para consignar cambios en el
repositorio central. Hasta entonces, no podrá almacenar sus cambios y
sus modificaciones locales correrán el riesgo de dañarse cuando trate
de actualizar su vista del repositorio.

\subsubsection{Las bifurcaciones(forks) no son un problema}

Se ha mencionado que las herramientas de control distribuido de
versiones albergan un riesgo a los proyectos de código abierto, puesto
que se vuelve muy sencillo hacer una ``bifurcanción''\ndt{fork.} del
desarrollo del proyecto.  Una bifurcación pasa cuando hay diferencias
de opinión o actitud entre grupos de desarrolladores que desenvoca en
la decisión de la imposibilidad de continuar trabajando juntos. Cada
parte toma una copia más o menos completa del código fuente del
proyecto y toma su propio rumbo.

En algunas ocasiones los líderes de las bifurcaciones reconcilian sus
diferencias. Con un sistema centralizado de control de revisiones, el
proceso \emph{técnico} de reconciliarse es doloroso, y se hace de
forma muy manual.  Tiene que decidir qué historia de revisiones va a
``win'', e injertar los cambios del otro equipo en el árbol de alguna
manera. Con esto usualmente se pierde algo o todo del historial de la
revisión de alguna de las partes.

Lo que las herramientas distribuidas hacen con respecto a las
bifurcaciones, es que las bifurcaciones son la \emph{única} forma de
desarrollar un proyecto. Cada cambio que usted hace es potencialmente
un punto de bifurcación. La gran fortaleza de esta aproximación es que
las herramientas distribuidas de control de revisiones tiene que ser
bueno al \emph{fusionar} las bifurcaciones, porque las bifurcaciones
son absolutamente fundamentales: pasan todo el tiempo.

Si todas las porciones de trabajo que todos hacen todo el tiempo, se
enmarca en términos de bifurcaciones y fusiones, entonces a aquello a
lo que se refiere en el mundo del código abierto a una ``bifurcación''
se convierte \emph{puramente} en una cuestión social. Lo que hacen las
herramientas distribuidas es \emph{disminuir} la posibilidad de una
bifurcación porque:
\begin{itemize}
\item Eliminan la distinción social que las herramientas centralizadas
  imponen: esto entre los miembros (personas con permiso de consignar)
  y forasteros(los que no tienen el permiso).
\item Facilitan la reconciliación después de una bifurcación social,
  porque todo lo que concierne al programa de control de revisiones es
  una fusión.
\end{itemize}

Algunas personas se resisten a las herramientas distribuidas porque
desean mantener control completo sobre sus proyectos, y creen que las
herramientas centralizadas les dan tal control. En todo caso, si este
es su parecer, y publica sus repositorios de CVS o Subversion, hay
muchas herramientas disponibles que pueden obtener la historia
completa(A pesar de lo lento) y recrearla en otro sitio que usted no
controla. Siendo así un control ilusorio, está impidiendo la fluidez
de colaboración frente a quien se sienta impulsado a obtener una copia
y hacer una bifurcación con su historia.

\subsection{Advantages for commercial projects}

Many commercial projects are undertaken by teams that are scattered
across the globe.  Contributors who are far from a central server will
see slower command execution and perhaps less reliability.  Commercial
revision control systems attempt to ameliorate these problems with
remote-site replication add-ons that are typically expensive to buy
and cantankerous to administer.  A distributed system doesn't suffer
from these problems in the first place.  Better yet, you can easily
set up multiple authoritative servers, say one per site, so that
there's no redundant communication between repositories over expensive
long-haul network links.

Centralised revision control systems tend to have relatively low
scalability.  It's not unusual for an expensive centralised system to
fall over under the combined load of just a few dozen concurrent
users.  Once again, the typical response tends to be an expensive and
clunky replication facility.  Since the load on a central server---if
you have one at all---is many times lower with a distributed
tool (because all of the data is replicated everywhere), a single
cheap server can handle the needs of a much larger team, and
replication to balance load becomes a simple matter of scripting.

If you have an employee in the field, troubleshooting a problem at a
customer's site, they'll benefit from distributed revision control.
The tool will let them generate custom builds, try different fixes in
isolation from each other, and search efficiently through history for
the sources of bugs and regressions in the customer's environment, all
without needing to connect to your company's network.

\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 if you're familiar with one, it is easy to
learn to use the other.  Both tools are portable to all popular
operating systems.

Prior to version 1.5, Subversion had no useful support for merges.
At the time of writing, its merge tracking capability is new, and known to be
\href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicated
  and buggy}.

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.  Because many Subversion commands must talk to
the server and Subversion does not have useful replication facilities,
server capacity and network bandwidth become bottlenecks for modestly
large projects.

Additionally, Subversion incurs 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}).  As a result, a Subversion
working copy is often 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 is widely supported by third party tools.  Mercurial
currently lags considerably in this area.  This gap is closing,
however, and indeed some of Mercurial's GUI tools now outshine their
Subversion equivalents.  Like Mercurial, Subversion has an excellent
user manual.

Because Subversion doesn't store revision history on the client, it is
well suited to managing projects that deal with lots of large, opaque
binary files.  If you check in fifty revisions to an incompressible
10MB file, Subversion's client-side space usage stays constant The
space used by any distributed SCM will grow rapidly in proportion to
the number of revisions, because the differences between each revision
are large.

In addition, it's often difficult or, more usually, impossible to
merge different versions of a binary file.  Subversion's ability to
let a user lock a file, so that they temporarily have the exclusive
right to commit changes to it, can be a significant advantage to a
project where binary files are widely used.

Mercurial can import revision history from a Subversion repository.
It can also export revision history to a Subversion repository.  This
makes it easy to ``test the waters'' and use Mercurial and Subversion
in parallel before deciding to switch.  History conversion is
incremental, so you can perform an initial conversion, then small
additional conversions afterwards to bring in new changes.


\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 a very large command set, with version~1.5.0 providing~139
individual commands.  It has something of a reputation for being
difficult to learn.  Compared to Git, Mercurial has a strong focus on
simplicity.

In terms of performance, Git is extremely fast.  In several cases, it
is faster than Mercurial, at least on Linux, while Mercurial performs
better on other operations.  However, on Windows, the performance and
general level of support that Git provides 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 several instances where scripts charged along
blindly in the presence of errors that should have been fatal.

Mercurial can import revision history from a Git repository.


\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 only
lightly maintained 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'': one person can successfully commit part of a
change and then be blocked by the need for a merge, causing other
people to see only a portion of the work they intended to do.  This
also affects how you work with project history.  If you want to see
all of the modifications someone made as part of a task, you will need
to manually inspect the descriptions and timestamps of the changes
made to each file involved (if you even know what those files were).

CVS has a muddled 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).

Mercurial can import revision history from a CVS repository.


\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.


\subsection{Choosing a revision control tool}

With the exception of CVS, all of the tools listed above have unique
strengths that suit them to particular styles of work.  There is no
single revision control tool that is best in all situations.

As an example, Subversion is a good choice for working with frequently
edited binary files, due to its centralised nature and support for
file locking.

I personally find Mercurial's properties of simplicity, performance,
and good merge support to be a compelling combination that has served
me well for several years.


\section{Switching from another tool to Mercurial}

Mercurial is bundled with an extension named \hgext{convert}, which
can incrementally import revision history from several other revision
control tools.  By ``incremental'', I mean that you can convert all of
a project's history to date in one go, then rerun the conversion later
to obtain new changes that happened after the initial conversion.

The revision control tools supported by \hgext{convert} are as
follows:
\begin{itemize}
\item Subversion
\item CVS
\item Git
\item Darcs
\end{itemize}

In addition, \hgext{convert} can export changes from Mercurial to
Subversion.  This makes it possible to try Subversion and Mercurial in
parallel before committing to a switchover, without risking the loss
of any work.

The \hgxcmd{conver}{convert} command is easy to use.  Simply point it
at the path or URL of the source repository, optionally give it the
name of the destination repository, and it will start working.  After
the initial conversion, just run the same command again to import new
changes.


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "00book"
%%% End: