Mercurial > hgbook
view es/concepts.tex @ 513:c7234c5d01b2
corrected typo
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Tue, 11 Nov 2008 23:14:03 -0500 |
parents | 006cd2b41d11 |
children | 0eda2936ef77 |
line wrap: on
line source
\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. Because it's possible for a video stream to ``drop out'' occasionally due to signal glitches, and to limit the accumulation of artefacts introduced by the lossy compression process, video encoders periodically insert a complete frame (called a ``key frame'') into the video stream; the next delta is generated against that frame. This means that if the video signal gets interrupted, it will resume once the next key frame is received. Also, the accumulation of encoding errors restarts anew with each key frame. \subsection{Identification and strong integrity} Along with delta or snapshot information, a revlog entry contains a cryptographic hash of the data that it represents. This makes it difficult to forge the contents of a revision, and easy to detect accidental corruption. Hashes provide more than a mere check against corruption; they are used as the identifiers for revisions. The changeset identification hashes that you see as an end user are from revisions of the changelog. Although filelogs and the manifest also use hashes, Mercurial only uses these behind the scenes. Mercurial verifies that hashes are correct when it retrieves file revisions and when it pulls changes from another repository. If it encounters an integrity problem, it will complain and stop whatever it's doing. In addition to the effect it has on retrieval efficiency, Mercurial's use of periodic snapshots makes it more robust against partial data corruption. If a revlog becomes partly corrupted due to a hardware error or system bug, it's often possible to reconstruct some or most revisions from the uncorrupted sections of the revlog, both before and after the corrupted section. This would not be possible with a delta-only storage model. \section{Revision history, branching, and merging} Every entry in a Mercurial revlog knows the identity of its immediate ancestor revision, usually referred to as its \emph{parent}. In fact, a revision contains room for not one parent, but two. Mercurial uses a special hash, called the ``null ID'', to represent the idea ``there is no parent here''. This hash is simply a string of zeroes. In figure~\ref{fig:concepts:revlog}, you can see an example of the conceptual structure of a revlog. Filelogs, manifests, and changelogs all have this same structure; they differ only in the kind of data stored in each delta or snapshot. The first revision in a revlog (at the bottom of the image) has the null ID in both of its parent slots. For a ``normal'' revision, its first parent slot contains the ID of its parent revision, and its second contains the null ID, indicating that the revision has only one real parent. Any two revisions that have the same parent ID are branches. A revision that represents a merge between branches has two normal revision IDs in its parent slots. \begin{figure}[ht] \centering \grafix{revlog} \caption{} \label{fig:concepts:revlog} \end{figure} \section{The working directory} In the working directory, Mercurial stores a snapshot of the files from the repository as of a particular changeset. The working directory ``knows'' which changeset it contains. When you update the working directory to contain a particular changeset, Mercurial looks up the appropriate revision of the manifest to find out which files it was tracking at the time that changeset was committed, and which revision of each file was then current. It then recreates a copy of each of those files, with the same contents it had when the changeset was committed. The \emph{dirstate} contains Mercurial's knowledge of the working directory. This details which changeset the working directory is updated to, and all of the files that Mercurial is tracking in the working directory. Just as a revision of a revlog has room for two parents, so that it can represent either a normal revision (with one parent) or a merge of two earlier revisions, the dirstate has slots for two parents. When you use the \hgcmd{update} command, the changeset that you update to is stored in the ``first parent'' slot, and the null ID in the second. When you \hgcmd{merge} with another changeset, the first parent remains unchanged, and the second parent is filled in with the changeset you're merging with. The \hgcmd{parents} command tells you what the parents of the dirstate are. \subsection{What happens when you commit} The dirstate stores parent information for more than just book-keeping purposes. Mercurial uses the parents of the dirstate as \emph{the parents of a new changeset} when you perform a commit. \begin{figure}[ht] \centering \grafix{wdir} \caption{The working directory can have two parents} \label{fig:concepts:wdir} \end{figure} Figure~\ref{fig:concepts:wdir} shows the normal state of the working directory, where it has a single changeset as parent. That changeset is the \emph{tip}, the newest changeset in the repository that has no children. \begin{figure}[ht] \centering \grafix{wdir-after-commit} \caption{The working directory gains new parents after a commit} \label{fig:concepts:wdir-after-commit} \end{figure} It's useful to think of the working directory as ``the changeset I'm about to commit''. Any files that you tell Mercurial that you've added, removed, renamed, or copied will be reflected in that changeset, as will modifications to any files that Mercurial is already tracking; the new changeset will have the parents of the working directory as its parents. After a commit, Mercurial will update the parents of the working directory, so that the first parent is the ID of the new changeset, and the second is the null ID. This is shown in figure~\ref{fig:concepts:wdir-after-commit}. Mercurial doesn't touch any of the files in the working directory when you commit; it just modifies the dirstate to note its new parents. \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: