jerojasro@393: \chapter{Tras bambalinas}
jerojasro@343: \label{chap:concepts}
jerojasro@343: 
jerojasro@393: A diferencia de varios sistemas de control de revisiones, los
jerojasro@393: conceptos en los que se fundamenta Mercurial son lo suficientemente
jerojasro@393: simples como para entender fácilmente cómo funciona el software. 
jerojasro@393: Saber esto no es necesario, pero considero útil tener un ``modelo
jerojasro@393: mental'' de qué es lo que sucede.
jerojasro@393: 
jerojasro@393: Comprender esto me da la confianza de que Mercurial ha sido
jerojasro@393: cuidadosamente diseñado para ser tanto \emph{seguro} como
jerojasro@393: \emph{eficiente}.  Y tal vez con la misma importancia, si es fácil
jerojasro@393: para mí hacerme a una idea adecuada de qué está haciendo el software
jerojasro@393: cuando llevo a cabo una tarea relacionada con control de revisiones,
jerojasro@393: es menos probable que me sosprenda su comportamiento.
jerojasro@393: 
jerojasro@393: En este capítulo, cubriremos inicialmente los conceptos centrales
jerojasro@393: del diseño de Mercurial, y luego discutiremos algunos detalles
jerojasro@393: interesantes de su implementación.
jerojasro@393: 
jerojasro@393: \section{Registro del historial de Mercurial}
jerojasro@393: 
jerojasro@393: \subsection{Seguir el historial de un único fichero}
jerojasro@393: 
jerojasro@393: Cuando Mercurial sigue las modificaciones a un fichero, guarda el
jerojasro@393: historial de dicho fichero en un objeto de metadatos llamado
jerojasro@395: \emph{filelog}\ndt{Fichero de registro}.  Cada entrada en el fichero
jerojasro@395: de registro contiene suficiente información para reconstruir una
jerojasro@395: revisión del fichero que se está siguiendo. Los ficheros de registro
jerojasro@395: son almacenados como ficheros el el directorio
jerojasro@395: \sdirname{.hg/store/data}. Un fichero de registro contiene dos tipos
jerojasro@395: de información: datos de revisiones, y un índice para ayudar a
jerojasro@395: Mercurial a buscar revisiones eficientemente.
jerojasro@395: 
jerojasro@395: El fichero de registro de un fichero grande, o con un historial muy
jerojasro@395: largo, es guardado como ficheros separados para datos (sufijo
jerojasro@395: ``\texttt{.d}'') y para el índice (sufijo ``\texttt{.i}''). Para
jerojasro@395: ficheros pequeños con un historial pequeño, los datos de revisiones y
jerojasro@395: el índice son combinados en un único fichero ``\texttt{.i}''. La
jerojasro@395: correspondencia entre un fichero en el directorio de trabajo y el
jerojasro@395: fichero de registro que hace seguimiento a su historial en el
jerojasro@395: repositorio se ilustra en la figura~\ref{fig:concepts:filelog}.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{filelog}
jerojasro@396:   \caption{Relación entre ficheros en el directorio de trabajo y
jerojasro@396:   ficheros de registro en el repositorio}
jerojasro@343:   \label{fig:concepts:filelog}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@396: \subsection{Administración de ficheros monitoreados}
jerojasro@396: 
jerojasro@396: Mercurial usa una estructura llamada \emph{manifiesto} para
jerojasro@396: % TODO collect together => centralizar
jerojasro@396: centralizar la información que maneja acerca de los ficheros que
jerojasro@396: monitorea. Cada entrada en el manifiesto contiene información acerca
jerojasro@396: de los ficheros involucrados en un único conjunto de cambios. Una
jerojasro@396: entrada registra qué ficheros están presentes en el conjunto de
jerojasro@396: cambios, la revisión de cada fichero, y otros cuantos metadatos del
jerojasro@396: mismo.
jerojasro@396: 
jerojasro@396: \subsection{Registro de información del conjunto de cambios}
jerojasro@396: 
jerojasro@396: La \emph{bitácora de cambios} contiene información acerca de cada
jerojasro@396: conjunto de cambios. Cada revisión indica quién consignó un cambio, el
jerojasro@396: comentario para el conjunto de cambios, otros datos relacionados con
jerojasro@396: el conjunto de cambios, y la revisión del manifiesto a usar.
jerojasro@396: 
jerojasro@396: \subsection{Relaciones entre revisiones}
jerojasro@396: 
jerojasro@396: Dentro de una bitácora de cambios, un manifiesto, o un fichero de
jerojasro@396: registro, cada revisión conserva un apuntador a su padre inmediato
jerojasro@396: (o sus dos padres, si es la revisión de una fusión). Como menciońe
jerojasro@396: anteriormente, también hay relaciones entre revisiones \emph{a través}
jerojasro@396: de estas estructuras, y tienen naturaleza jerárquica.
jerojasro@396: 
jerojasro@396: Por cada conjunto de cambios en un repositorio, hay exactamente una
jerojasro@396: revisión almacenada en la bitácora de cambios. Cada revisión de la
jerojasro@396: bitácora de cambios contiene un apuntador a una única revisión del
jerojasro@396: manifiesto. Una revisión del manifiesto almacena un apuntador a una
jerojasro@396: única revisión de cada fichero de registro al que se le hacía
jerojasro@396: seguimiento cuando fue creado el conjunto de cambios. Estas relaciones
jerojasro@396: se ilustran en la figura~\ref{fig:concepts:metadata}.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{metadata}
jerojasro@396:   \caption{Relaciones entre metadatos}
jerojasro@343:   \label{fig:concepts:metadata}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@406: Como lo muestra la figura, \emph{no} hay una relación ``uno a uno''
jerojasro@406: entre las revisiones en el conjunto de cambios, el manifiesto, o el
jerojasro@406: fichero de registro. Si el manifiesto no ha sido modificado de un
jerojasro@406: conjunto de cambios a otro, las entradas en la bitácora de cambios
jerojasro@406: para esos conjuntos de cambios apuntarán a la misma revisión del
jerojasro@406: manifiesto. Si un fichero monitoreado por Mercurial no sufre ningún
jerojasro@406: cambio de un conjunto de cambios a otro, la entrada para dicho fichero
jerojasro@406: en las dos revisiones del manifiesto apuntará a la misma revisión de
jerojasro@406: su fichero de registro.
jerojasro@406: 
jerojasro@406: \section{Almacenamiento seguro y eficiente}
jerojasro@406: 
jerojasro@406: La base común de las bitácoras de cambios, los manifiestos, y los
jerojasro@406: ficheros de registros es provista por una única estructura llamada el
jerojasro@406: \emph{revlog}\ndt{Contracción de \emph{revision log}, registro de
jerojasro@406: revisión.}.
jerojasro@406: 
jerojasro@406: \subsection{Almacenamiento eficiente}
jerojasro@406: 
jerojasro@406: El revlog provee almacenamiento eficiente de revisiones por medio del
jerojasro@406: mecanismo de \emph{deltas}\ndt{Diferencias.}.  En vez de almacenar una
jerojasro@406: copia completa del fichero por cada revisión, almacena los cambios
jerojasro@406: necesarios para transformar una revisión anterior en la nueva
jerojasro@406: revisión. Para muchos tipos de fichero, estos deltas son típicamente
jerojasro@406: de una fracción porcentual del tamaño de una copia completa del
jerojasro@406: fichero.
jerojasro@406: 
jerojasro@406: Algunos sistemas de control de revisiones obsoletos sólo pueden
jerojasro@406: manipular deltas de ficheros de texto plano. Ellos o bien almacenan
jerojasro@406: los ficheros binarios como instantáneas completas, o codificados en
jerojasro@406: alguna representación de texto plano adecuada, y ambas alternativas
jerojasro@406: son enfoques que desperdician bastantes recursos. Mercurial puede
jerojasro@406: manejar deltas de ficheros con contenido binario arbitrario; no
jerojasro@406: necesita tratar el texto plano como un caso especial.
jerojasro@343: 
jerojasro@410: \subsection{Operación segura}
jerojasro@343: \label{sec:concepts:txn}
jerojasro@343: 
jerojasro@410: Mercurial sólo \emph{añade} datos al final de los ficheros de revlog. Nunca
jerojasro@410: modifica ninguna sección de un fichero una vez ha sido escrita. Esto es más
jerojasro@410: robusto y eficiente que otros esquemas que requieren modificar o reescribir
jerojasro@410: datos.
jerojasro@410: 
jerojasro@410: Adicionalmente, Mercurial trata cada escritura como parte de una
jerojasro@410: \emph{transacción}, que puede cubrir varios ficheros. Una transacción es
jerojasro@410: \emph{atómica}: o bien la transacción tiene éxito y entonces todos sus efectos
jerojasro@410: son visibles para todos los lectores, o la operación completa es cancelada.
jerojasro@410: % TODO atomicidad no existe de acuerdo a DRAE, reemplazar
jerojasro@410: Esta garantía de atomicidad implica que, si usted está ejecutando dos copias de
jerojasro@410: Mercurial, donde una de ellas está leyendo datos y la otra los está escribiendo,
jerojasro@410: el lector nunca verá un resultado escrito parcialmente que podría confundirlo.
jerojasro@410: 
jerojasro@410: El hecho de que Mercurial sólo hace adiciones a los ficheros hace más fácil
jerojasro@410: proveer esta garantía transaccional. A medida que sea más fácil hacer
jerojasro@410: operaciones como ésta, más confianza tendrá usted en que sean hechas
jerojasro@410: correctamente.
jerojasro@410: 
jerojasro@410: \subsection{Recuperación rápida de datos}
jerojasro@410: 
jerojasro@410: Mercurial evita ingeniosamente un problema común a todos los sistemas de control
jerojasro@410: de revisiones anteriores> el problema de la
jerojasro@410: \emph{recuperación\ndt{\emph{Retrieval}. Recuperación en el sentido de traer los
jerojasro@410: datos, o reconstruirlos a partir de otros datos, pero no debido a una falla o
jerojasro@410: calamidad, sino a la operación normal del sistema.} ineficiente de datos}.
jerojasro@410: Muchos sistemas de control de revisiones almacenan los contenidos de una
jerojasro@410: revisión como una serie incremental de modificaciones a una ``instantánea''.
jerojasro@410: Para reconstruir una versión cualquiera, primero usted debe leer la instantánea,
jerojasro@410: y luego cada una de las revisiones entre la instantánea y su versión objetivo.
jerojasro@410: Entre más largo sea el historial de un fichero, más revisiones deben ser leídas,
jerojasro@410: y por tanto toma más tiempo reconstruir una versión particular.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{snapshot}
jerojasro@410:   \caption{Instantánea de un revlog, con deltas incrementales}
jerojasro@343:   \label{fig:concepts:snapshot}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@410: La innovación que aplica Mercurial a este problema es simple pero efectiva.
jerojasro@410: Una vez la cantidad de información de deltas acumulada desde la última
jerojasro@410: instantánea excede un umbral fijado de antemano, se almacena una nueva
jerojasro@410: instantánea (comprimida, por supuesto), en lugar de otro delta. Esto hace
jerojasro@410: posible reconstruir \emph{cualquier} versión de un fichero rápidamente. Este
jerojasro@410: enfoque funciona tan bien que desde entonces ha sido copiado por otros sistemas
jerojasro@410: de control de revisiones.
jerojasro@410: 
jerojasro@410: La figura~\ref{fig:concepts:snapshot} ilustra la idea. En una entrada en el
jerojasro@410: fichero índice de un revlog, Mercurial almacena el rango de entradas (deltas)
jerojasro@410: del fichero de datos que se deben leer para reconstruir una revisión en
jerojasro@410: particular.
jerojasro@410: 
jerojasro@410: \subsubsection{Nota al margen: la influencia de la compresión de vídeo}
jerojasro@410: 
jerojasro@410: Si le es familiar la compresión de vídeo, o ha mirado alguna vez una emisión de
jerojasro@410: TV a través de cable digital o un servicio de satélite, puede que sepa que la 
jerojasro@410: mayor parte de los esquemas de compresión de vídeo almacenan cada cuadro del
jerojasro@410: mismo como un delta contra el cuadro predecesor. Adicionalmente, estos esquemas
jerojasro@411: usan técnicas de compresión ``con pérdida'' para aumentar la tasa de
jerojasro@410: compresión, por lo que los errores visuales se acumulan a lo largo de una
jerojasro@410: cantidad de deltas inter-cuadros.
jerojasro@343: 
jerojasro@415: Ya que existe la posibilidad de que un flujo de vídeo se ``pierda''
jerojasro@415: ocasionalmente debido a fallas en la señal, y para limitar la acumulación de
jerojasro@415: errores introducida por la compresión con pérdidas, los codificadores de vídeo
jerojasro@415: insertan periódicamente un cuadro completo (también llamado ``cuadro clave'') en
jerojasro@415: el flujo de vídeo; el siguiente delta es generado con respecto a dicho cuadro.
jerojasro@415: Esto quiere decir que si la señal de vídeo se interrumpe, se reanudará una vez
jerojasro@415: se reciba el siguiente cuadro clave. Además, la acumulación de errores de
jerojasro@415: codificación se reinicia con cada cuadro clave.
jerojasro@415: 
jerojasro@415: \subsection{Identificación e integridad fuerte}
jerojasro@415: 
jerojasro@416: Además de la información de deltas e instantáneas, una entrada en un
jerojasro@415: % TODO de pronto aclarar qué diablos es un hash?
jerojasro@416: revlog contiene un hash criptográfico de los datos que representa.
jerojasro@416: Esto hace difícil falsificar el contenido de una revisión, y hace
jerojasro@416: fácil detectar una corrupción accidental.
jerojasro@416: 
jerojasro@416: Los hashes proveen más que una simple revisión de corrupción: son
jerojasro@416: usados como los identificadores para las revisiones. 
jerojasro@416: % TODO no entendí completamente la frase a continuación
jerojasro@416: Los hashes de
jerojasro@416: identificación de conjuntos de cambios que usted ve como usuario final
jerojasro@416: son de las revisiones de la bitácora de cambios. Aunque los ficheros
jerojasro@416: de registro y el manifiesto también usan hashes, Mercurial sólo los
jerojasro@416: usa tras bambalinas.
jerojasro@416: 
jerojasro@416: Mercurial verifica que los hashes sean correctos cuando recupera
jerojasro@416: revisiones de ficheros y cuando jala cambios desde otro repositorio.
jerojasro@416: Si se encuentra un problema de integridad, Mercurial se quejará y
jerojasro@416: detendrá cualquier operación que esté haciendo.
jerojasro@416: 
jerojasro@416: Además del efecto que tiene en la eficiencia en la recuperación, el
jerojasro@416: uso periódico de instantáneas de Mercurial lo hace más robusto frente
jerojasro@416: a la corrupción parcial de datos. Si un fichero de registro se
jerojasro@416: corrompe parcialmente debido a un error de hardware o del sistema, a
jerojasro@416: menudo es posible reconstruir algunas o la mayoría de las revisiones a
jerojasro@416: partir de las secciones no corrompidas del fichero de registro, tanto
jerojasro@416: antes como después de la sección corrompida. Esto no sería posible con
jerojasro@416: un sistema de almacenamiento basado únicamente en deltas.
jerojasro@343: 
jerojasro@418: \section{Historial de revisiones, ramas y fusiones}
jerojasro@418: 
jerojasro@418: Cada entrada en el revlog de Mercurial conoce la identidad de la
jerojasro@418: revisión de su ancestro inmediato, al que se conoce usualmente como su
jerojasro@418: \emph{padre}. De hecho, una revisión contiene sitio no sólo para un
jerojasro@418: padre, sino para dos. Mercurial usa un hash especial, llamado el
jerojasro@418: ``ID nulo'', para representar la idea de ``no hay padre aquí''. Este
jerojasro@418: hash es simplemente una cadena de ceros.
jerojasro@418: 
jerojasro@418: En la figura~\ref{fig:concepts:revlog} usted puede ver un ejemplo de
jerojasro@418: la estructura conceptual de un revlog. Los ficheros de registro,
jerojasro@418: manifiestos, y bitácoras de cambios comparten la misma estructura;
jerojasro@418: sólo difieren en el tipo de datos almacenados en cada delta o
jerojasro@418: instantánea.
jerojasro@418: 
jerojasro@418: La primera revisión en un revlog (al final de la imagen) tiene como
jerojasro@418: padre al ID nulo, en las dos ranuras disponibles para padres. En una
jerojasro@418: revisión normal, la primera ranura para padres contiene el ID de la
jerojasro@418: revisión padre, y la segunda contiene el ID nulo, señalando así que la
jerojasro@418: revisión sólo tiene un padre real. Un par de revisiones que tenga el
jerojasro@418: mismo ID padre son ramas. Una revisión que representa una fusión entre
jerojasro@418: ramas tiene dos IDs de revisión normales en sus ranuras para padres.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{revlog}
jerojasro@343:   \caption{}
jerojasro@343:   \label{fig:concepts:revlog}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@420: \section{El directorio de trabajo}
jerojasro@420: 
jerojasro@420: % TODO revisar párrafo, no me convence la traducción
jerojasro@420: En el directorio de trabajo, Mercurial almacena una instantánea de los
jerojasro@420: ficheros  del repositorio como si fueran los de un conjunto de cambios
jerojasro@420: particular.
jerojasro@420: 
jerojasro@420: El directorio de trabajo ``sabe'' qué conjunto de cambios contiene.
jerojasro@420: Cuando usted actualiza el directorio de trabajo para que contenga un
jerojasro@420: conjunto de cambios particular, Mercurial busca la revisión adecuada
jerojasro@420: del manifiesto para averiguar qué ficheros estaba monitoreando cuando
jerojasro@420: se hizo la consignación del conjunto de cambios, y qué revisión de
jerojasro@420: cada fichero era la actual en ese momento. Luego de eso, recrea una
jerojasro@420: copia de cada uno de esos ficheros, con los mismos contenidos que
jerojasro@420: tenían cuando fue consignado el conjunto de cambios.
jerojasro@420: 
jerojasro@420: El \emph{estado de directorio}\ndt{dirstate, en inglés en el
jerojasro@420: original.} contiene el conocimiento de Mercurial acerca del directorio
jerojasro@420: de trabajo. Allí se detalla a qué conjunto de cambios es actualizado
jerojasro@420: el directorio de trabajo, y todos los ficheros que Mercurial está
jerojasro@420: monitoreando en este directorio.
jerojasro@420: 
jerojasro@420: Tal como la revisión de un revlog tiene espacio para dos padres, para
jerojasro@420: que pueda representar tanto una revisión normal (con un solo padre) o
jerojasro@420: una fusión de dos revisiones anteriores, el estado de directorio tiene
jerojasro@420: espacio para dos padres. Cuando usted usa el comando \hgcmd{update},
jerojasro@420: el conjunto de cambios al que usted se actualiza es almacenado en la
jerojasro@420: casilla destinada al ``primer padre'', y un ID nulo es almacenado en
jerojasro@420: la segunda. Cuando usted hace una fusión (\hgcmd{merge}) con otro
jerojasro@420: conjunto de cambios, la casilla para el primer padre permanece sin
jerojasro@420: cambios, y la casilla para el segundo es actualizada con el conjunto
jerojasro@420: de cambios con el que usted acaba de hacer la fusión. El comando
jerojasro@420: \hgcmd{parents} le indica cuáles son los padres del estado de
jerojasro@420: directorio.
jerojasro@420: 
jerojasro@420: \subsection{Qué pasa en una consignación}
jerojasro@420: 
jerojasro@420: El estado de directorio almacena información sobre los padres para
jerojasro@420: algo más que mero registro. Mercurial usa los padres del estado de
jerojasro@420: directorio como \emph{los padres de un nuevo conjunto de cambios}
jerojasro@420: cuando usted hace una consignación.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{wdir}
jerojasro@420:   \caption{El directorio de trabajo puede tener dos padres}
jerojasro@343:   \label{fig:concepts:wdir}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@420: La figura~\ref{fig:concepts:wdir} muestra el estado normal del
jerojasro@420: directorio de trabajo, que tiene un único conjunto de cambios como
jerojasro@420: padre. Dicho conjunto de cambios es la \emph{punta}, el conjunto de
jerojasro@420: cambios más reciente en el repositorio que no tiene hijos.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{wdir-after-commit}
jerojasro@420:   \caption{El directorio de trabajo obtiene nuevos padres luego de una
jerojasro@420:   consignación}
jerojasro@343:   \label{fig:concepts:wdir-after-commit}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@420: Es útil pensar en el directorio de trabajo como en ``el conjunto de
jerojasro@420: cambios que estoy a punto de enviar''. Cualquier fichero que usted le
jerojasro@420: diga a Mercurial que fue añadido, borrado, renombrado o copiado, se
jerojasro@420: verá reflejado en ese conjunto de cambios, como también se verán las
jerojasro@420: modificaciones a cualquiera de los ficheros que Mercurial ya esté
jerojasro@420: monitoreando; el nuevo conjunto de cambios dentrá los padres del
jerojasro@420: directorio de trabajo como propios.
jerojasro@420: 
jerojasro@420: Luego de una consignación, Mercurial actualizará los padres del
jerojasro@420: directorio de trabajo, de tal manera que el primer padre sea el ID del
jerojasro@420: nuevo conjunto de cambios, y el segundo sea el ID nulo. Esto puede
jerojasro@420: verse en la figura~\ref{fig:concepts:wdir-after-commit}.  Mercurial no
jerojasro@420: toca ninguno de los ficheros del directorio de trabajo cuando usted
jerojasro@420: hace la consignación; sólo modifica el estado de directorio para
jerojasro@420: anotar sus nuevos padres.
jerojasro@343: 
jerojasro@422: \subsection{Creación de un nuevo frente}
jerojasro@422: 
jerojasro@422: Es perfectamente normal actualizar el directorio de trabajo a un
jerojasro@422: conjunto de cambios diferente a la punta actual. Por ejemplo, usted
jerojasro@422: podría desear saber en qué estado se encontraba su proyecto el martes
jerojasro@422: pasado, o podría estar buscando en todos los conjuntos de cambios para
jerojasro@422: saber cuándo se introdujo un fallo. En casos como éstos, la acción
jerojasro@422: natural es actualizar el directorio de trabajo al conjunto de cambios
jerojasro@422: de su interés, y examinar directamente los ficheros en el directorio
jerojasro@422: de trabajo para ver sus contenidos tal como estaban en el momento de
jerojasro@422: hacer la consignación. El efecto que tiene esto se muestra en la
jerojasro@422: figura~\ref{fig:concepts:wdir-pre-branch}.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{wdir-pre-branch}
jerojasro@422:   \caption{El directorio de trabajo, actualizado a un conjunto de
jerojasro@422:   cambios anterior}
jerojasro@343:   \label{fig:concepts:wdir-pre-branch}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@422: Una vez se ha actualizado el directorio de trabajo a un conjunto de
jerojasro@422: cambios anterior, qué pasa si se hacen cambios, y luego se hace una
jerojasro@422: consignación? Mercurial se comporta en la misma forma que describí
jerojasro@422: anteriormente. Los padres del directorio de trabajo se convierten en
jerojasro@422: los padres del nuevo conjunto de cambios. Este nuevo conjunto de
jerojasro@422: cambios no tiene hijos, así que se convierte en la nueva punta. Y el
jerojasro@422: repositorio tiene ahora dos conjuntos de cambios que no tienen hijos;
jerojasro@422: a éstos los llamamos \emph{frentes}. Usted puede apreciar la
jerojasro@422: estructura que esto crea en la figura~\ref{fig:concepts:wdir-branch}.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{wdir-branch}
jerojasro@422:   \caption{Después de una consignación hecha mientras se usaba un
jerojasro@422:   conjunto de cambios anterior}
jerojasro@343:   \label{fig:concepts:wdir-branch}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@343: \begin{note}
jerojasro@422:     Si usted es nuevo en Mercurial, debería tener en mente un
jerojasro@422:     ``error'' común, que es usar el comando \hgcmd{pull} sin ninguna
jerojasro@422:     opción. Por defecto, el comando \hgcmd{pull} \emph{no} actualiza
jerojasro@422:     el directorio de trabajo, así que usted termina trayendo nuevos
jerojasro@422:     conjuntos de cambios a su repositorio, pero el directorio de
jerojasro@422:     trabajo sigue usando el mismo conjunto de cambios que tenía antes
jerojasro@422:     de jalar. Si usted hace algunos cambios, y luego hace una
jerojasro@422:     consignación, estará creando un nuevo frente, porque su directorio
jerojasro@422:     de trabajo no es sincronizado a cualquiera que sea la nueva punta.
jerojasro@422: 
jerojasro@422:     Pongo la palabra ``error'' en comillas porque todo lo que usted
jerojasro@422:     debe hacer para rectificar la situación es hacer una fusión
jerojasro@422:     (\hgcmd{merge}), y luego una consignación (\hgcmd{commit}). En
jerojasro@422:     otras palabras, esto casi nunca tiene consecuencias negativas;
jerojasro@422:     sólo sorprende a la gente. Discutiré otras formas de evitar este
jerojasro@422:     comportamiento, y porqué Mercurial se comporta de esta forma,
jerojasro@422:     inicialmente sorprendente, más adelante.
jerojasro@343: \end{note}
jerojasro@343: 
jerojasro@422: \subsection{Fusión de frentes}
jerojasro@422: 
jerojasro@422: Cuando usted ejecuta el comando \hgcmd{merge}, Mercurial deja el
jerojasro@422: primer padre del directorio de trabajo intacto, y escribe como segundo
jerojasro@422: padre el conjunto de cambios contra el cual usted está haciendo la
jerojasro@422: fusión, como se muestra en la figura~\ref{fig:concepts:wdir-merge}.
jerojasro@343: 
jerojasro@343: \begin{figure}[ht]
jerojasro@343:   \centering
jerojasro@343:   \grafix{wdir-merge}
jerojasro@422:   \caption{Fusión de dos frentes}
jerojasro@343:   \label{fig:concepts:wdir-merge}
jerojasro@343: \end{figure}
jerojasro@343: 
jerojasro@422: Mercurial también debe modificar el directorio de trabajo, para
jerojasro@422: fusionar los ficheros que él monitorea en los dos conjuntos de
jerojasro@422: cambios. Con algunas simplificaciones, el proceso es el siguiente, por
jerojasro@422: cada fichero en los manifiestos de ambos conjuntos de cambios.
jerojasro@343: \begin{itemize}
jerojasro@422: \item Si ningún conjunto de cambios ha modificado un fichero, no se
jerojasro@422:     hace nada con el mismo.
jerojasro@422: \item Si un conjunto de cambios ha modificado un fichero, y el otro no
jerojasro@422:     lo ha hecho, se crea una copia del fichero con las modificaciones
jerojasro@422:     pertinentes en el directorio de trabajo.
jerojasro@422: \item Si un conjunto de cambios borra un fichero, y el otro no lo ha
jerojasro@422:     hecho (o también lo borró), se borra dicho fichero del directorio
jerojasro@422:     de trabajo.
jerojasro@422: \item Si un conjunto de cambios ha borrado un fichero, pero el otro lo ha
jerojasro@422:     modificado, se le pregunta al usuario qué hacer: conservar el
jerojasro@422:     fichero modificado, o borrarlo?
jerojasro@422: \item Si ambos conjuntos de cambios han modificado un fichero, se
jerojasro@422:     invoca el programa externo de fusión para definir el nuevo
jerojasro@422:     contenido del fichero fusionado. Esto puede requerir interacción
jerojasro@422:     directa de parte del usuario.
jerojasro@422: \item Si un conjunto de cambios ha modificado un fichero, y el otro ha
jerojasro@422:     renombrado o copiado el mismo, asegurarse de que los cambios sigan
jerojasro@422:     al nuevo nombre de fichero.
jerojasro@343: \end{itemize}
jerojasro@422: Hay más detalles---hacer una fusión tiene una gran cantidad de casos
jerojasro@422: especiales---pero éstas son las elecciones más comunes que se ven
jerojasro@422: involucradas en una fusión. Como usted puede ver, muchos de los casos
jerojasro@422: son completamente automáticos, y de hecho la mayoría de las fusiones
jerojasro@422: terminan automáticamente, sin requerir la interacción del usuario para
jerojasro@422: resolver ningún conflicto.
jerojasro@343: 
jerojasro@423: Cuando considere qué pasa cuando usted hace una consignación después
jerojasro@423: de una fusión, de nuevo el directorio de trabajo es ``el conjunto de
jerojasro@423: cambios que estoy a punto de consignar''. Una vez termina su trabajo
jerojasro@423: el comando \hgcmd{merge}, el directorio de trabajo tiene dos padre;
jerojasro@423: éstos se convertirán en los padres del nuevo conjunto de cambios.
jerojasro@423: 
jerojasro@423: Mercurial le permite hacer múltiples fusiones, pero usted debe
jerojasro@423: consignar los resultados de cada fusión sucesivamente. Esto es
jerojasro@423: necesario porque Mercurial sólo monitorea dos padres, tanto para las
jerojasro@423: revisiones como para los directorios de trabajo. Aunque técnicamente
jerojasro@423: es posible fusionar varios conjuntos de trabajo en una sola operación,
jerojasro@423: la posibilidad de confundir al usuario y crear un desorden terrible en
jerojasro@423: la fusión se hace incontenible de inmediato.
jerojasro@423: 
jerojasro@423: \section{Otras características de diseño interesantes}
jerojasro@423: 
jerojasro@423: En las secciones anteriores, he tratado de resaltar algunos de los
jerojasro@423: aspectos más importantes del diseño de Mercurial, para mostrar que se
jerojasro@423: presta gran cuidado y atención a la confiabilidad y el desempeño. Sin
jerojasro@423: embargo, la atención a los detalles no para ahí. Hay una cantidad de
jerojasro@423: aspectos de la construcción de Mercurial que encuentro interesantes
jerojasro@423: personalmente. Detallaré unos cuantos de ellos aquí, aparte de los
jerojasro@423: elementos ``importantes'' de arriba, para que, si usted está
jerojasro@423: % TODO the amount of thinking => (la cantidad de) esfuerzo mental
jerojasro@423: interesado, pueda obetener una idea mejor de la cantidad de esfuerzo
jerojasro@423: mental invertido en el diseño de un sistema bien diseñado.
jerojasro@423: 
jerojasro@423: 
jerojasro@423: \subsection{Compresión ingeniosa}
jerojasro@423: 
jerojasro@423: Cuando es adecuado, Mercurial almacenará tanto las instantáneas como
jerojasro@423: los deltas en formato comprimido. Lo hace \emph{tratando} siempre de
jerojasro@423: comprimir una instantánea o delta, y conservando la versión comprimida
jerojasro@423: sólo si es más pequeña que la versión sin compresión.
jerojasro@423: 
jerojasro@423: Esto implica que Mercurial hace ``lo correcto'' cuando almacena un
jerojasro@423: fichero cuyo formato original está comprimido, como un fichero
jerojasro@423: \texttt{zip} o una imagen JPEG.  Cuando estos tipos de ficheros son
jerojasro@423: comprimidos por segunda vez, el fichero resultante usualmente es más
jerojasro@423: grande que la versión comprimida una sola vez, por lo que Mercurial
jerojasro@423: almacenará el fichero \texttt{zip} o JPEG original.
jerojasro@423: 
jerojasro@423: Los deltas entre revisiones de un fichero comprimido usualmente son
jerojasro@423: más grandes que las instantáneas del mismo fichero, y Mercurial de
jerojasro@423: nuevo hace ``lo correcto'' en estos casos. Él encuentra que dicho
jerojasro@423: delta excede el umbral respecto al cual se debería almacenar una
jerojasro@423: instantánea completa del fichero, así que almacena la instantánea,
jerojasro@423: ahorrando espacio de nuevo respecto al enfoque simplista de usar
jerojasro@423: únicamente deltas.
jerojasro@423: 
jerojasro@423: \subsubsection{Recompresión de red}
jerojasro@423: 
jerojasro@423: Cuando almacena las revisiones en disco, Mercurial usa el algoritmo de
jerojasro@423: compresión ``deflación'' (el mismo usado en el popular formato de
jerojasro@423: fichero \texttt{zip}), que provee una buena velocidad con una tasa de
jerojasro@423: compresión respetable. Sin embargo, cuando se transmiten datos de
jerojasro@423: revisiones a través de una conexión de red, Mercurial descomprime los
jerojasro@423: datos comprimidos de las revisiones.
jerojasro@423: 
jerojasro@423: Si la conexión es hecha a través de HTTP, Mercurial recomprime el
jerojasro@423: flujo completo de datos usando un algoritmo de compresión que brinda
jerojasro@423: una mejor tasa de compresión (el algoritmo Burrows-Wheeler de el
jerojasro@423: ampliamente usado paquete de compresión \texttt{bzip2}). Esta
jerojasro@423: combinación de algoritmo y compresión del flujo completo de datos
jerojasro@423: (en vez de una revisión a la vez) reduce sustancialmente la cantidad
jerojasro@423: de bytes a transferir, brindando así un mejor desempeño de red sobre
jerojasro@423: casi todo tipo de redes.
jerojasro@423: 
jerojasro@423: (Si la conexión se hace sobre \command{ssh}, Mercurial \emph{no}
jerojasro@423: recomprmime el flujo, porque \command{ssh} puede hacer esto por sí
jerojasro@423: mismo.)
jerojasro@343: 
jerojasro@343: \subsection{Read/write ordering and atomicity}
jerojasro@343: 
jerojasro@343: Appending to files isn't the whole story when it comes to guaranteeing
jerojasro@343: that a reader won't see a partial write.  If you recall
jerojasro@343: figure~\ref{fig:concepts:metadata}, revisions in the changelog point to
jerojasro@343: revisions in the manifest, and revisions in the manifest point to
jerojasro@343: revisions in filelogs.  This hierarchy is deliberate.
jerojasro@343: 
jerojasro@343: A writer starts a transaction by writing filelog and manifest data,
jerojasro@343: and doesn't write any changelog data until those are finished.  A
jerojasro@343: reader starts by reading changelog data, then manifest data, followed
jerojasro@343: by filelog data.
jerojasro@343: 
jerojasro@343: Since the writer has always finished writing filelog and manifest data
jerojasro@343: before it writes to the changelog, a reader will never read a pointer
jerojasro@343: to a partially written manifest revision from the changelog, and it will
jerojasro@343: never read a pointer to a partially written filelog revision from the
jerojasro@343: manifest.
jerojasro@343: 
jerojasro@343: \subsection{Concurrent access}
jerojasro@343: 
jerojasro@343: The read/write ordering and atomicity guarantees mean that Mercurial
jerojasro@343: never needs to \emph{lock} a repository when it's reading data, even
jerojasro@343: if the repository is being written to while the read is occurring.
jerojasro@343: This has a big effect on scalability; you can have an arbitrary number
jerojasro@343: of Mercurial processes safely reading data from a repository safely
jerojasro@343: all at once, no matter whether it's being written to or not.
jerojasro@343: 
jerojasro@343: The lockless nature of reading means that if you're sharing a
jerojasro@343: repository on a multi-user system, you don't need to grant other local
jerojasro@343: users permission to \emph{write} to your repository in order for them
jerojasro@343: to be able to clone it or pull changes from it; they only need
jerojasro@343: \emph{read} permission.  (This is \emph{not} a common feature among
jerojasro@343: revision control systems, so don't take it for granted!  Most require
jerojasro@343: readers to be able to lock a repository to access it safely, and this
jerojasro@343: requires write permission on at least one directory, which of course
jerojasro@343: makes for all kinds of nasty and annoying security and administrative
jerojasro@343: problems.)
jerojasro@343: 
jerojasro@343: Mercurial uses locks to ensure that only one process can write to a
jerojasro@343: repository at a time (the locking mechanism is safe even over
jerojasro@343: filesystems that are notoriously hostile to locking, such as NFS).  If
jerojasro@343: a repository is locked, a writer will wait for a while to retry if the
jerojasro@343: repository becomes unlocked, but if the repository remains locked for
jerojasro@343: too long, the process attempting to write will time out after a while.
jerojasro@343: This means that your daily automated scripts won't get stuck forever
jerojasro@343: and pile up if a system crashes unnoticed, for example.  (Yes, the
jerojasro@343: timeout is configurable, from zero to infinity.)
jerojasro@343: 
jerojasro@343: \subsubsection{Safe dirstate access}
jerojasro@343: 
jerojasro@343: As with revision data, Mercurial doesn't take a lock to read the
jerojasro@343: dirstate file; it does acquire a lock to write it.  To avoid the
jerojasro@343: possibility of reading a partially written copy of the dirstate file,
jerojasro@343: Mercurial writes to a file with a unique name in the same directory as
jerojasro@343: the dirstate file, then renames the temporary file atomically to
jerojasro@343: \filename{dirstate}.  The file named \filename{dirstate} is thus
jerojasro@343: guaranteed to be complete, not partially written.
jerojasro@343: 
jerojasro@343: \subsection{Avoiding seeks}
jerojasro@343: 
jerojasro@343: Critical to Mercurial's performance is the avoidance of seeks of the
jerojasro@343: disk head, since any seek is far more expensive than even a
jerojasro@343: comparatively large read operation.
jerojasro@343: 
jerojasro@343: This is why, for example, the dirstate is stored in a single file.  If
jerojasro@343: there were a dirstate file per directory that Mercurial tracked, the
jerojasro@343: disk would seek once per directory.  Instead, Mercurial reads the
jerojasro@343: entire single dirstate file in one step.
jerojasro@343: 
jerojasro@343: Mercurial also uses a ``copy on write'' scheme when cloning a
jerojasro@343: repository on local storage.  Instead of copying every revlog file
jerojasro@343: from the old repository into the new repository, it makes a ``hard
jerojasro@343: link'', which is a shorthand way to say ``these two names point to the
jerojasro@343: same file''.  When Mercurial is about to write to one of a revlog's
jerojasro@343: files, it checks to see if the number of names pointing at the file is
jerojasro@343: greater than one.  If it is, more than one repository is using the
jerojasro@343: file, so Mercurial makes a new copy of the file that is private to
jerojasro@343: this repository.
jerojasro@343: 
jerojasro@343: A few revision control developers have pointed out that this idea of
jerojasro@343: making a complete private copy of a file is not very efficient in its
jerojasro@343: use of storage.  While this is true, storage is cheap, and this method
jerojasro@343: gives the highest performance while deferring most book-keeping to the
jerojasro@343: operating system.  An alternative scheme would most likely reduce
jerojasro@343: performance and increase the complexity of the software, each of which
jerojasro@343: is much more important to the ``feel'' of day-to-day use.
jerojasro@343: 
jerojasro@343: \subsection{Other contents of the dirstate}
jerojasro@343: 
jerojasro@343: Because Mercurial doesn't force you to tell it when you're modifying a
jerojasro@343: file, it uses the dirstate to store some extra information so it can
jerojasro@343: determine efficiently whether you have modified a file.  For each file
jerojasro@343: in the working directory, it stores the time that it last modified the
jerojasro@343: file itself, and the size of the file at that time.  
jerojasro@343: 
jerojasro@343: When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or
jerojasro@343: \hgcmd{copy} files, Mercurial updates the dirstate so that it knows
jerojasro@343: what to do with those files when you commit.
jerojasro@343: 
jerojasro@343: When Mercurial is checking the states of files in the working
jerojasro@343: directory, it first checks a file's modification time.  If that has
jerojasro@343: not changed, the file must not have been modified.  If the file's size
jerojasro@343: has changed, the file must have been modified.  If the modification
jerojasro@343: time has changed, but the size has not, only then does Mercurial need
jerojasro@343: to read the actual contents of the file to see if they've changed.
jerojasro@343: Storing these few extra pieces of information dramatically reduces the
jerojasro@343: amount of data that Mercurial needs to read, which yields large
jerojasro@343: performance improvements compared to other revision control systems.
jerojasro@343: 
jerojasro@343: %%% Local Variables: 
jerojasro@343: %%% mode: latex
jerojasro@343: %%% TeX-master: "00book"
jerojasro@343: %%% End: