annotate es/concepts.tex @ 519:0774efad9003

translated up to section 4.4.1 (included). updated the project status file

\chapter{Tras bambalinas}
\label{chap:concepts}

A diferencia de varios sistemas de control de revisiones, los
conceptos en los que se fundamenta Mercurial son lo suficientemente
simples como para entender fácilmente cómo funciona el software. 
Saber esto no es necesario, pero considero útil tener un ``modelo
mental'' de qué es lo que sucede.

Comprender esto me da la confianza de que Mercurial ha sido
cuidadosamente diseñado para ser tanto \emph{seguro} como
\emph{eficiente}.  Y tal vez con la misma importancia, si es fácil
para mí hacerme a una idea adecuada de qué está haciendo el software
cuando llevo a cabo una tarea relacionada con control de revisiones,
es menos probable que me sosprenda su comportamiento.

En este capítulo, cubriremos inicialmente los conceptos centrales
del diseño de Mercurial, y luego discutiremos algunos detalles
interesantes de su implementación.

\section{Registro del historial de Mercurial}

\subsection{Seguir el historial de un único fichero}

Cuando Mercurial sigue las modificaciones a un fichero, guarda el
historial de dicho fichero en un objeto de metadatos llamado
\emph{filelog}\ndt{Fichero de registro}.  Cada entrada en el fichero
de registro contiene suficiente información para reconstruir una
revisión del fichero que se está siguiendo. Los ficheros de registro
son almacenados como ficheros el el directorio
\sdirname{.hg/store/data}. Un fichero de registro contiene dos tipos
de información: datos de revisiones, y un índice para ayudar a
Mercurial a buscar revisiones eficientemente.

El fichero de registro de un fichero grande, o con un historial muy
largo, es guardado como ficheros separados para datos (sufijo
``\texttt{.d}'') y para el índice (sufijo ``\texttt{.i}''). Para
ficheros pequeños con un historial pequeño, los datos de revisiones y
el índice son combinados en un único fichero ``\texttt{.i}''. La
correspondencia entre un fichero en el directorio de trabajo y el
fichero de registro que hace seguimiento a su historial en el
repositorio se ilustra en la figura~\ref{fig:concepts:filelog}.

\begin{figure}[ht]
  \centering
  \grafix{filelog}
  \caption{Relación entre ficheros en el directorio de trabajo y
  ficheros de registro en el repositorio}
  \label{fig:concepts:filelog}
\end{figure}

\subsection{Administración de ficheros monitoreados}

Mercurial usa una estructura llamada \emph{manifiesto} para
% TODO collect together => centralizar
centralizar la información que maneja acerca de los ficheros que
monitorea. Cada entrada en el manifiesto contiene información acerca
de los ficheros involucrados en un único conjunto de cambios. Una
entrada registra qué ficheros están presentes en el conjunto de
cambios, la revisión de cada fichero, y otros cuantos metadatos del
mismo.

\subsection{Registro de información del conjunto de cambios}

La \emph{bitácora de cambios} contiene información acerca de cada
conjunto de cambios. Cada revisión indica quién consignó un cambio, el
comentario para el conjunto de cambios, otros datos relacionados con
el conjunto de cambios, y la revisión del manifiesto a usar.

\subsection{Relaciones entre revisiones}

Dentro de una bitácora de cambios, un manifiesto, o un fichero de
registro, cada revisión conserva un apuntador a su padre inmediato
(o sus dos padres, si es la revisión de una fusión). Como menciońe
anteriormente, también hay relaciones entre revisiones \emph{a través}
de estas estructuras, y tienen naturaleza jerárquica.

Por cada conjunto de cambios en un repositorio, hay exactamente una
revisión almacenada en la bitácora de cambios. Cada revisión de la
bitácora de cambios contiene un apuntador a una única revisión del
manifiesto. Una revisión del manifiesto almacena un apuntador a una
única revisión de cada fichero de registro al que se le hacía
seguimiento cuando fue creado el conjunto de cambios. Estas relaciones
se ilustran en la figura~\ref{fig:concepts:metadata}.

\begin{figure}[ht]
  \centering
  \grafix{metadata}
  \caption{Relaciones entre metadatos}
  \label{fig:concepts:metadata}
\end{figure}

Como lo muestra la figura, \emph{no} hay una relación ``uno a uno''
entre las revisiones en el conjunto de cambios, el manifiesto, o el
fichero de registro. Si el manifiesto no ha sido modificado de un
conjunto de cambios a otro, las entradas en la bitácora de cambios
para esos conjuntos de cambios apuntarán a la misma revisión del
manifiesto. Si un fichero monitoreado por Mercurial no sufre ningún
cambio de un conjunto de cambios a otro, la entrada para dicho fichero
en las dos revisiones del manifiesto apuntará a la misma revisión de
su fichero de registro.

\section{Almacenamiento seguro y eficiente}

La base común de las bitácoras de cambios, los manifiestos, y los
ficheros de registros es provista por una única estructura llamada el
\emph{revlog}\ndt{Contracción de \emph{revision log}, registro de
revisión.}.

\subsection{Almacenamiento eficiente}

El revlog provee almacenamiento eficiente de revisiones por medio del
mecanismo de \emph{deltas}\ndt{Diferencias.}.  En vez de almacenar una
copia completa del fichero por cada revisión, almacena los cambios
necesarios para transformar una revisión anterior en la nueva
revisión. Para muchos tipos de fichero, estos deltas son típicamente
de una fracción porcentual del tamaño de una copia completa del
fichero.

Algunos sistemas de control de revisiones obsoletos sólo pueden
manipular deltas de ficheros de texto plano. Ellos o bien almacenan
los ficheros binarios como instantáneas completas, o codificados en
alguna representación de texto plano adecuada, y ambas alternativas
son enfoques que desperdician bastantes recursos. Mercurial puede
manejar deltas de ficheros con contenido binario arbitrario; no
necesita tratar el texto plano como un caso especial.

\subsection{Operación segura}
\label{sec:concepts:txn}

Mercurial sólo \emph{añade} datos al final de los ficheros de revlog. Nunca
modifica ninguna sección de un fichero una vez ha sido escrita. Esto es más
robusto y eficiente que otros esquemas que requieren modificar o reescribir
datos.

Adicionalmente, Mercurial trata cada escritura como parte de una
\emph{transacción}, que puede cubrir varios ficheros. Una transacción es
\emph{atómica}: o bien la transacción tiene éxito y entonces todos sus efectos
son visibles para todos los lectores, o la operación completa es cancelada.
% TODO atomicidad no existe de acuerdo a DRAE, reemplazar
Esta garantía de atomicidad implica que, si usted está ejecutando dos copias de
Mercurial, donde una de ellas está leyendo datos y la otra los está escribiendo,
el lector nunca verá un resultado escrito parcialmente que podría confundirlo.

El hecho de que Mercurial sólo hace adiciones a los ficheros hace más fácil
proveer esta garantía transaccional. A medida que sea más fácil hacer
operaciones como ésta, más confianza tendrá usted en que sean hechas
correctamente.

\subsection{Recuperación rápida de datos}

Mercurial evita ingeniosamente un problema común a todos los sistemas de control
de revisiones anteriores> el problema de la
\emph{recuperación\ndt{\emph{Retrieval}. Recuperación en el sentido de traer los
datos, o reconstruirlos a partir de otros datos, pero no debido a una falla o
calamidad, sino a la operación normal del sistema.} ineficiente de datos}.
Muchos sistemas de control de revisiones almacenan los contenidos de una
revisión como una serie incremental de modificaciones a una ``instantánea''.
Para reconstruir una versión cualquiera, primero usted debe leer la instantánea,
y luego cada una de las revisiones entre la instantánea y su versión objetivo.
Entre más largo sea el historial de un fichero, más revisiones deben ser leídas,
y por tanto toma más tiempo reconstruir una versión particular.

\begin{figure}[ht]
  \centering
  \grafix{snapshot}
  \caption{Instantánea de un revlog, con deltas incrementales}
  \label{fig:concepts:snapshot}
\end{figure}

La innovación que aplica Mercurial a este problema es simple pero efectiva.
Una vez la cantidad de información de deltas acumulada desde la última
instantánea excede un umbral fijado de antemano, se almacena una nueva
instantánea (comprimida, por supuesto), en lugar de otro delta. Esto hace
posible reconstruir \emph{cualquier} versión de un fichero rápidamente. Este
enfoque funciona tan bien que desde entonces ha sido copiado por otros sistemas
de control de revisiones.

La figura~\ref{fig:concepts:snapshot} ilustra la idea. En una entrada en el
fichero índice de un revlog, Mercurial almacena el rango de entradas (deltas)
del fichero de datos que se deben leer para reconstruir una revisión en
particular.

\subsubsection{Nota al margen: la influencia de la compresión de vídeo}

Si le es familiar la compresión de vídeo, o ha mirado alguna vez una emisión de
TV a través de cable digital o un servicio de satélite, puede que sepa que la 
mayor parte de los esquemas de compresión de vídeo almacenan cada cuadro del
mismo como un delta contra el cuadro predecesor. Adicionalmente, estos esquemas
usan técnicas de compresión ``con pérdida'' para aumentar la tasa de
compresión, por lo que los errores visuales se acumulan a lo largo de una
cantidad de deltas inter-cuadros.

Ya que existe la posibilidad de que un flujo de vídeo se ``pierda''
ocasionalmente debido a fallas en la señal, y para limitar la acumulación de
errores introducida por la compresión con pérdidas, los codificadores de vídeo
insertan periódicamente un cuadro completo (también llamado ``cuadro clave'') en
el flujo de vídeo; el siguiente delta es generado con respecto a dicho cuadro.
Esto quiere decir que si la señal de vídeo se interrumpe, se reanudará una vez
se reciba el siguiente cuadro clave. Además, la acumulación de errores de
codificación se reinicia con cada cuadro clave.

\subsection{Identificación e integridad fuerte}

Además de la información de deltas e instantáneas, una entrada en un
% TODO de pronto aclarar qué diablos es un hash?
revlog contiene un hash criptográfico de los datos que representa.
Esto hace difícil falsificar el contenido de una revisión, y hace
fácil detectar una corrupción accidental.

Los hashes proveen más que una simple revisión de corrupción: son
usados como los identificadores para las revisiones. 
% TODO no entendí completamente la frase a continuación
Los hashes de
identificación de conjuntos de cambios que usted ve como usuario final
son de las revisiones de la bitácora de cambios. Aunque los ficheros
de registro y el manifiesto también usan hashes, Mercurial sólo los
usa tras bambalinas.

Mercurial verifica que los hashes sean correctos cuando recupera
revisiones de ficheros y cuando jala cambios desde otro repositorio.
Si se encuentra un problema de integridad, Mercurial se quejará y
detendrá cualquier operación que esté haciendo.

Además del efecto que tiene en la eficiencia en la recuperación, el
uso periódico de instantáneas de Mercurial lo hace más robusto frente
a la corrupción parcial de datos. Si un fichero de registro se
corrompe parcialmente debido a un error de hardware o del sistema, a
menudo es posible reconstruir algunas o la mayoría de las revisiones a
partir de las secciones no corrompidas del fichero de registro, tanto
antes como después de la sección corrompida. Esto no sería posible con
un sistema de almacenamiento basado únicamente en deltas.

\section{Historial de revisiones, ramas y fusiones}

Cada entrada en el revlog de Mercurial conoce la identidad de la
revisión de su ancestro inmediato, al que se conoce usualmente como su
\emph{padre}. De hecho, una revisión contiene sitio no sólo para un
padre, sino para dos. Mercurial usa un hash especial, llamado el
``ID nulo'', para representar la idea de ``no hay padre aquí''. Este
hash es simplemente una cadena de ceros.

En la figura~\ref{fig:concepts:revlog} usted puede ver un ejemplo de
la estructura conceptual de un revlog. Los ficheros de registro,
manifiestos, y bitácoras de cambios comparten la misma estructura;
sólo difieren en el tipo de datos almacenados en cada delta o
instantánea.

La primera revisión en un revlog (al final de la imagen) tiene como
padre al ID nulo, en las dos ranuras disponibles para padres. En una
revisión normal, la primera ranura para padres contiene el ID de la
revisión padre, y la segunda contiene el ID nulo, señalando así que la
revisión sólo tiene un padre real. Un par de revisiones que tenga el
mismo ID padre son ramas. Una revisión que representa una fusión entre
ramas tiene dos IDs de revisión normales en sus ranuras para padres.

\begin{figure}[ht]
  \centering
  \grafix{revlog}
  \caption{}
  \label{fig:concepts:revlog}
\end{figure}

\section{El directorio de trabajo}

% TODO revisar párrafo, no me convence la traducción
En el directorio de trabajo, Mercurial almacena una instantánea de los
ficheros  del repositorio como si fueran los de un conjunto de cambios
particular.

El directorio de trabajo ``sabe'' qué conjunto de cambios contiene.
Cuando usted actualiza el directorio de trabajo para que contenga un
conjunto de cambios particular, Mercurial busca la revisión adecuada
del manifiesto para averiguar qué ficheros estaba monitoreando cuando
se hizo la consignación del conjunto de cambios, y qué revisión de
cada fichero era la actual en ese momento. Luego de eso, recrea una
copia de cada uno de esos ficheros, con los mismos contenidos que
tenían cuando fue consignado el conjunto de cambios.

El \emph{estado de directorio}\ndt{dirstate, en inglés en el
original.} contiene el conocimiento de Mercurial acerca del directorio
de trabajo. Allí se detalla a qué conjunto de cambios es actualizado
el directorio de trabajo, y todos los ficheros que Mercurial está
monitoreando en este directorio.

Tal como la revisión de un revlog tiene espacio para dos padres, para
que pueda representar tanto una revisión normal (con un solo padre) o
una fusión de dos revisiones anteriores, el estado de directorio tiene
espacio para dos padres. Cuando usted usa el comando \hgcmd{update},
el conjunto de cambios al que usted se actualiza es almacenado en la
casilla destinada al ``primer padre'', y un ID nulo es almacenado en
la segunda. Cuando usted hace una fusión (\hgcmd{merge}) con otro
conjunto de cambios, la casilla para el primer padre permanece sin
cambios, y la casilla para el segundo es actualizada con el conjunto
de cambios con el que usted acaba de hacer la fusión. El comando
\hgcmd{parents} le indica cuáles son los padres del estado de
directorio.

\subsection{Qué pasa en una consignación}

El estado de directorio almacena información sobre los padres para
algo más que mero registro. Mercurial usa los padres del estado de
directorio como \emph{los padres de un nuevo conjunto de cambios}
cuando usted hace una consignación.

\begin{figure}[ht]
  \centering
  \grafix{wdir}
  \caption{El directorio de trabajo puede tener dos padres}
  \label{fig:concepts:wdir}
\end{figure}

La figura~\ref{fig:concepts:wdir} muestra el estado normal del
directorio de trabajo, que tiene un único conjunto de cambios como
padre. Dicho conjunto de cambios es la \emph{punta}, el conjunto de
cambios más reciente en el repositorio que no tiene hijos.

\begin{figure}[ht]
  \centering
  \grafix{wdir-after-commit}
  \caption{El directorio de trabajo obtiene nuevos padres luego de una
  consignación}
  \label{fig:concepts:wdir-after-commit}
\end{figure}

Es útil pensar en el directorio de trabajo como en ``el conjunto de
cambios que estoy a punto de enviar''. Cualquier fichero que usted le
diga a Mercurial que fue añadido, borrado, renombrado o copiado, se
verá reflejado en ese conjunto de cambios, como también se verán las
modificaciones a cualquiera de los ficheros que Mercurial ya esté
monitoreando; el nuevo conjunto de cambios dentrá los padres del
directorio de trabajo como propios.

Luego de una consignación, Mercurial actualizará los padres del
directorio de trabajo, de tal manera que el primer padre sea el ID del
nuevo conjunto de cambios, y el segundo sea el ID nulo. Esto puede
verse en la figura~\ref{fig:concepts:wdir-after-commit}.  Mercurial no
toca ninguno de los ficheros del directorio de trabajo cuando usted
hace la consignación; sólo modifica el estado de directorio para
anotar sus nuevos padres.

\subsection{Creating a new head}

It's perfectly normal to update the working directory to a changeset
other than the current tip.  For example, you might want to know what
your project looked like last Tuesday, or you could be looking through
changesets to see which one introduced a bug.  In cases like this, the
natural thing to do is update the working directory to the changeset
you're interested in, and then examine the files in the working
directory directly to see their contents as they werea when you
committed that changeset.  The effect of this is shown in
figure~\ref{fig:concepts:wdir-pre-branch}.

\begin{figure}[ht]
  \centering
  \grafix{wdir-pre-branch}
  \caption{The working directory, updated to an older changeset}
  \label{fig:concepts:wdir-pre-branch}
\end{figure}

Having updated the working directory to an older changeset, what
happens if you make some changes, and then commit?  Mercurial behaves
in the same way as I outlined above.  The parents of the working
directory become the parents of the new changeset.  This new changeset
has no children, so it becomes the new tip.  And the repository now
contains two changesets that have no children; we call these
\emph{heads}.  You can see the structure that this creates in
figure~\ref{fig:concepts:wdir-branch}.

\begin{figure}[ht]
  \centering
  \grafix{wdir-branch}
  \caption{After a commit made while synced to an older changeset}
  \label{fig:concepts:wdir-branch}
\end{figure}

\begin{note}
  If you're new to Mercurial, you should keep in mind a common
  ``error'', which is to use the \hgcmd{pull} command without any
  options.  By default, the \hgcmd{pull} command \emph{does not}
  update the working directory, so you'll bring new changesets into
  your repository, but the working directory will stay synced at the
  same changeset as before the pull.  If you make some changes and
  commit afterwards, you'll thus create a new head, because your
  working directory isn't synced to whatever the current tip is.

  I put the word ``error'' in quotes because all that you need to do
  to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}.  In
  other words, this almost never has negative consequences; it just
  surprises people.  I'll discuss other ways to avoid this behaviour,
  and why Mercurial behaves in this initially surprising way, later
  on.
\end{note}

\subsection{Merging heads}

When you run the \hgcmd{merge} command, Mercurial leaves the first
parent of the working directory unchanged, and sets the second parent
to the changeset you're merging with, as shown in
figure~\ref{fig:concepts:wdir-merge}.

\begin{figure}[ht]
  \centering
  \grafix{wdir-merge}
  \caption{Merging two heads}
  \label{fig:concepts:wdir-merge}
\end{figure}

Mercurial also has to modify the working directory, to merge the files
managed in the two changesets.  Simplified a little, the merging
process goes like this, for every file in the manifests of both
changesets.
\begin{itemize}
\item If neither changeset has modified a file, do nothing with that
  file.
\item If one changeset has modified a file, and the other hasn't,
  create the modified copy of the file in the working directory.
\item If one changeset has removed a file, and the other hasn't (or
  has also deleted it), delete the file from the working directory.
\item If one changeset has removed a file, but the other has modified
  the file, ask the user what to do: keep the modified file, or remove
  it?
\item If both changesets have modified a file, invoke an external
  merge program to choose the new contents for the merged file.  This
  may require input from the user.
\item If one changeset has modified a file, and the other has renamed
  or copied the file, make sure that the changes follow the new name
  of the file.
\end{itemize}
There are more details---merging has plenty of corner cases---but
these are the most common choices that are involved in a merge.  As
you can see, most cases are completely automatic, and indeed most
merges finish automatically, without requiring your input to resolve
any conflicts.

When you're thinking about what happens when you commit after a merge,
once again the working directory is ``the changeset I'm about to
commit''.  After the \hgcmd{merge} command completes, the working
directory has two parents; these will become the parents of the new
changeset.

Mercurial lets you perform multiple merges, but you must commit the
results of each individual merge as you go.  This is necessary because
Mercurial only tracks two parents for both revisions and the working
directory.  While it would be technically possible to merge multiple
changesets at once, the prospect of user confusion and making a
terrible mess of a merge immediately becomes overwhelming.

\section{Other interesting design features}

In the sections above, I've tried to highlight some of the most
important aspects of Mercurial's design, to illustrate that it pays
careful attention to reliability and performance.  However, the
attention to detail doesn't stop there.  There are a number of other
aspects of Mercurial's construction that I personally find
interesting.  I'll detail a few of them here, separate from the ``big
ticket'' items above, so that if you're interested, you can gain a
better idea of the amount of thinking that goes into a well-designed
system.

\subsection{Clever compression}

When appropriate, Mercurial will store both snapshots and deltas in
compressed form.  It does this by always \emph{trying to} compress a
snapshot or delta, but only storing the compressed version if it's
smaller than the uncompressed version.

This means that Mercurial does ``the right thing'' when storing a file
whose native form is compressed, such as a \texttt{zip} archive or a
JPEG image.  When these types of files are compressed a second time,
the resulting file is usually bigger than the once-compressed form,
and so Mercurial will store the plain \texttt{zip} or JPEG.

Deltas between revisions of a compressed file are usually larger than
snapshots of the file, and Mercurial again does ``the right thing'' in
these cases.  It finds that such a delta exceeds the threshold at
which it should store a complete snapshot of the file, so it stores
the snapshot, again saving space compared to a naive delta-only
approach.

\subsubsection{Network recompression}

When storing revisions on disk, Mercurial uses the ``deflate''
compression algorithm (the same one used by the popular \texttt{zip}
archive format), which balances good speed with a respectable
compression ratio.  However, when transmitting revision data over a
network connection, Mercurial uncompresses the compressed revision
data.

If the connection is over HTTP, Mercurial recompresses the entire
stream of data using a compression algorithm that gives a better
compression ratio (the Burrows-Wheeler algorithm from the widely used
\texttt{bzip2} compression package).  This combination of algorithm
and compression of the entire stream (instead of a revision at a time)
substantially reduces the number of bytes to be transferred, yielding
better network performance over almost all kinds of network.

(If the connection is over \command{ssh}, Mercurial \emph{doesn't}
recompress the stream, because \command{ssh} can already do this
itself.)

\subsection{Read/write ordering and atomicity}

Appending to files isn't the whole story when it comes to guaranteeing
that a reader won't see a partial write.  If you recall
figure~\ref{fig:concepts:metadata}, revisions in the changelog point to
revisions in the manifest, and revisions in the manifest point to
revisions in filelogs.  This hierarchy is deliberate.

A writer starts a transaction by writing filelog and manifest data,
and doesn't write any changelog data until those are finished.  A
reader starts by reading changelog data, then manifest data, followed
by filelog data.

Since the writer has always finished writing filelog and manifest data
before it writes to the changelog, a reader will never read a pointer
to a partially written manifest revision from the changelog, and it will
never read a pointer to a partially written filelog revision from the
manifest.

\subsection{Concurrent access}

The read/write ordering and atomicity guarantees mean that Mercurial
never needs to \emph{lock} a repository when it's reading data, even
if the repository is being written to while the read is occurring.
This has a big effect on scalability; you can have an arbitrary number
of Mercurial processes safely reading data from a repository safely
all at once, no matter whether it's being written to or not.

The lockless nature of reading means that if you're sharing a
repository on a multi-user system, you don't need to grant other local
users permission to \emph{write} to your repository in order for them
to be able to clone it or pull changes from it; they only need
\emph{read} permission.  (This is \emph{not} a common feature among
revision control systems, so don't take it for granted!  Most require
readers to be able to lock a repository to access it safely, and this
requires write permission on at least one directory, which of course
makes for all kinds of nasty and annoying security and administrative
problems.)

Mercurial uses locks to ensure that only one process can write to a
repository at a time (the locking mechanism is safe even over
filesystems that are notoriously hostile to locking, such as NFS).  If
a repository is locked, a writer will wait for a while to retry if the
repository becomes unlocked, but if the repository remains locked for
too long, the process attempting to write will time out after a while.
This means that your daily automated scripts won't get stuck forever
and pile up if a system crashes unnoticed, for example.  (Yes, the
timeout is configurable, from zero to infinity.)

\subsubsection{Safe dirstate access}

As with revision data, Mercurial doesn't take a lock to read the
dirstate file; it does acquire a lock to write it.  To avoid the
possibility of reading a partially written copy of the dirstate file,
Mercurial writes to a file with a unique name in the same directory as
the dirstate file, then renames the temporary file atomically to
\filename{dirstate}.  The file named \filename{dirstate} is thus
guaranteed to be complete, not partially written.

\subsection{Avoiding seeks}

Critical to Mercurial's performance is the avoidance of seeks of the
disk head, since any seek is far more expensive than even a
comparatively large read operation.

This is why, for example, the dirstate is stored in a single file.  If
there were a dirstate file per directory that Mercurial tracked, the
disk would seek once per directory.  Instead, Mercurial reads the
entire single dirstate file in one step.

Mercurial also uses a ``copy on write'' scheme when cloning a
repository on local storage.  Instead of copying every revlog file
from the old repository into the new repository, it makes a ``hard
link'', which is a shorthand way to say ``these two names point to the
same file''.  When Mercurial is about to write to one of a revlog's
files, it checks to see if the number of names pointing at the file is
greater than one.  If it is, more than one repository is using the
file, so Mercurial makes a new copy of the file that is private to
this repository.

A few revision control developers have pointed out that this idea of
making a complete private copy of a file is not very efficient in its
use of storage.  While this is true, storage is cheap, and this method
gives the highest performance while deferring most book-keeping to the
operating system.  An alternative scheme would most likely reduce
performance and increase the complexity of the software, each of which
is much more important to the ``feel'' of day-to-day use.

\subsection{Other contents of the dirstate}

Because Mercurial doesn't force you to tell it when you're modifying a
file, it uses the dirstate to store some extra information so it can
determine efficiently whether you have modified a file.  For each file
in the working directory, it stores the time that it last modified the
file itself, and the size of the file at that time.  

When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or
\hgcmd{copy} files, Mercurial updates the dirstate so that it knows
what to do with those files when you commit.

When Mercurial is checking the states of files in the working
directory, it first checks a file's modification time.  If that has
not changed, the file must not have been modified.  If the file's size
has changed, the file must have been modified.  If the modification
time has changed, but the size has not, only then does Mercurial need
to read the actual contents of the file to see if they've changed.
Storing these few extra pieces of information dramatically reduces the
amount of data that Mercurial needs to read, which yields large
performance improvements compared to other revision control systems.

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