hgbook

annotate es/concepts.tex @ 624:3c5e1c03cc3e

find changesets by author, revision, files, or words in the commit message
Add XSL stylesheets for DocBook
author Dongsheng Song <dongsheng.song@gmail.com>
date Thu Mar 12 15:47:15 2009 +0800 (2009-03-12)
parents 3f32047a3f25
children
rev   line source
jerojasro@393 1 \chapter{Tras bambalinas}
jerojasro@343 2 \label{chap:concepts}
jerojasro@343 3
jerojasro@393 4 A diferencia de varios sistemas de control de revisiones, los
jerojasro@393 5 conceptos en los que se fundamenta Mercurial son lo suficientemente
jerojasro@393 6 simples como para entender fácilmente cómo funciona el software.
jerojasro@393 7 Saber esto no es necesario, pero considero útil tener un ``modelo
jerojasro@393 8 mental'' de qué es lo que sucede.
jerojasro@393 9
jerojasro@393 10 Comprender esto me da la confianza de que Mercurial ha sido
jerojasro@393 11 cuidadosamente diseñado para ser tanto \emph{seguro} como
jerojasro@393 12 \emph{eficiente}. Y tal vez con la misma importancia, si es fácil
jerojasro@393 13 para mí hacerme a una idea adecuada de qué está haciendo el software
jerojasro@393 14 cuando llevo a cabo una tarea relacionada con control de revisiones,
jerojasro@393 15 es menos probable que me sosprenda su comportamiento.
jerojasro@393 16
jerojasro@393 17 En este capítulo, cubriremos inicialmente los conceptos centrales
jerojasro@393 18 del diseño de Mercurial, y luego discutiremos algunos detalles
jerojasro@393 19 interesantes de su implementación.
jerojasro@393 20
jerojasro@393 21 \section{Registro del historial de Mercurial}
jerojasro@393 22
jerojasro@393 23 \subsection{Seguir el historial de un único fichero}
jerojasro@393 24
jerojasro@393 25 Cuando Mercurial sigue las modificaciones a un fichero, guarda el
jerojasro@393 26 historial de dicho fichero en un objeto de metadatos llamado
jerojasro@395 27 \emph{filelog}\ndt{Fichero de registro}. Cada entrada en el fichero
jerojasro@395 28 de registro contiene suficiente información para reconstruir una
jerojasro@395 29 revisión del fichero que se está siguiendo. Los ficheros de registro
jerojasro@395 30 son almacenados como ficheros el el directorio
jerojasro@395 31 \sdirname{.hg/store/data}. Un fichero de registro contiene dos tipos
jerojasro@395 32 de información: datos de revisiones, y un índice para ayudar a
jerojasro@395 33 Mercurial a buscar revisiones eficientemente.
jerojasro@395 34
jerojasro@395 35 El fichero de registro de un fichero grande, o con un historial muy
jerojasro@395 36 largo, es guardado como ficheros separados para datos (sufijo
jerojasro@395 37 ``\texttt{.d}'') y para el índice (sufijo ``\texttt{.i}''). Para
jerojasro@395 38 ficheros pequeños con un historial pequeño, los datos de revisiones y
jerojasro@395 39 el índice son combinados en un único fichero ``\texttt{.i}''. La
jerojasro@395 40 correspondencia entre un fichero en el directorio de trabajo y el
jerojasro@395 41 fichero de registro que hace seguimiento a su historial en el
jerojasro@395 42 repositorio se ilustra en la figura~\ref{fig:concepts:filelog}.
jerojasro@343 43
jerojasro@343 44 \begin{figure}[ht]
jerojasro@343 45 \centering
jerojasro@343 46 \grafix{filelog}
jerojasro@396 47 \caption{Relación entre ficheros en el directorio de trabajo y
jerojasro@396 48 ficheros de registro en el repositorio}
jerojasro@343 49 \label{fig:concepts:filelog}
jerojasro@343 50 \end{figure}
jerojasro@343 51
jerojasro@396 52 \subsection{Administración de ficheros monitoreados}
jerojasro@396 53
jerojasro@396 54 Mercurial usa una estructura llamada \emph{manifiesto} para
jerojasro@396 55 % TODO collect together => centralizar
jerojasro@396 56 centralizar la información que maneja acerca de los ficheros que
jerojasro@396 57 monitorea. Cada entrada en el manifiesto contiene información acerca
jerojasro@396 58 de los ficheros involucrados en un único conjunto de cambios. Una
jerojasro@396 59 entrada registra qué ficheros están presentes en el conjunto de
jerojasro@396 60 cambios, la revisión de cada fichero, y otros cuantos metadatos del
jerojasro@396 61 mismo.
jerojasro@396 62
jerojasro@396 63 \subsection{Registro de información del conjunto de cambios}
jerojasro@396 64
jerojasro@396 65 La \emph{bitácora de cambios} contiene información acerca de cada
jerojasro@396 66 conjunto de cambios. Cada revisión indica quién consignó un cambio, el
jerojasro@396 67 comentario para el conjunto de cambios, otros datos relacionados con
jerojasro@396 68 el conjunto de cambios, y la revisión del manifiesto a usar.
jerojasro@396 69
jerojasro@396 70 \subsection{Relaciones entre revisiones}
jerojasro@396 71
jerojasro@396 72 Dentro de una bitácora de cambios, un manifiesto, o un fichero de
jerojasro@396 73 registro, cada revisión conserva un apuntador a su padre inmediato
jerojasro@396 74 (o sus dos padres, si es la revisión de una fusión). Como menciońe
jerojasro@396 75 anteriormente, también hay relaciones entre revisiones \emph{a través}
jerojasro@396 76 de estas estructuras, y tienen naturaleza jerárquica.
jerojasro@396 77
jerojasro@396 78 Por cada conjunto de cambios en un repositorio, hay exactamente una
jerojasro@396 79 revisión almacenada en la bitácora de cambios. Cada revisión de la
jerojasro@396 80 bitácora de cambios contiene un apuntador a una única revisión del
jerojasro@396 81 manifiesto. Una revisión del manifiesto almacena un apuntador a una
jerojasro@396 82 única revisión de cada fichero de registro al que se le hacía
jerojasro@396 83 seguimiento cuando fue creado el conjunto de cambios. Estas relaciones
jerojasro@396 84 se ilustran en la figura~\ref{fig:concepts:metadata}.
jerojasro@343 85
jerojasro@343 86 \begin{figure}[ht]
jerojasro@343 87 \centering
jerojasro@343 88 \grafix{metadata}
jerojasro@396 89 \caption{Relaciones entre metadatos}
jerojasro@343 90 \label{fig:concepts:metadata}
jerojasro@343 91 \end{figure}
jerojasro@343 92
jerojasro@406 93 Como lo muestra la figura, \emph{no} hay una relación ``uno a uno''
jerojasro@406 94 entre las revisiones en el conjunto de cambios, el manifiesto, o el
jerojasro@406 95 fichero de registro. Si el manifiesto no ha sido modificado de un
jerojasro@406 96 conjunto de cambios a otro, las entradas en la bitácora de cambios
jerojasro@406 97 para esos conjuntos de cambios apuntarán a la misma revisión del
jerojasro@406 98 manifiesto. Si un fichero monitoreado por Mercurial no sufre ningún
jerojasro@406 99 cambio de un conjunto de cambios a otro, la entrada para dicho fichero
jerojasro@406 100 en las dos revisiones del manifiesto apuntará a la misma revisión de
jerojasro@406 101 su fichero de registro.
jerojasro@406 102
jerojasro@406 103 \section{Almacenamiento seguro y eficiente}
jerojasro@406 104
jerojasro@406 105 La base común de las bitácoras de cambios, los manifiestos, y los
jerojasro@406 106 ficheros de registros es provista por una única estructura llamada el
jerojasro@406 107 \emph{revlog}\ndt{Contracción de \emph{revision log}, registro de
jerojasro@406 108 revisión.}.
jerojasro@406 109
jerojasro@406 110 \subsection{Almacenamiento eficiente}
jerojasro@406 111
jerojasro@406 112 El revlog provee almacenamiento eficiente de revisiones por medio del
jerojasro@406 113 mecanismo de \emph{deltas}\ndt{Diferencias.}. En vez de almacenar una
jerojasro@406 114 copia completa del fichero por cada revisión, almacena los cambios
jerojasro@406 115 necesarios para transformar una revisión anterior en la nueva
jerojasro@406 116 revisión. Para muchos tipos de fichero, estos deltas son típicamente
jerojasro@406 117 de una fracción porcentual del tamaño de una copia completa del
jerojasro@406 118 fichero.
jerojasro@406 119
jerojasro@406 120 Algunos sistemas de control de revisiones obsoletos sólo pueden
jerojasro@406 121 manipular deltas de ficheros de texto plano. Ellos o bien almacenan
jerojasro@406 122 los ficheros binarios como instantáneas completas, o codificados en
jerojasro@406 123 alguna representación de texto plano adecuada, y ambas alternativas
jerojasro@406 124 son enfoques que desperdician bastantes recursos. Mercurial puede
jerojasro@406 125 manejar deltas de ficheros con contenido binario arbitrario; no
jerojasro@406 126 necesita tratar el texto plano como un caso especial.
jerojasro@343 127
jerojasro@410 128 \subsection{Operación segura}
jerojasro@343 129 \label{sec:concepts:txn}
jerojasro@343 130
jerojasro@410 131 Mercurial sólo \emph{añade} datos al final de los ficheros de revlog. Nunca
jerojasro@410 132 modifica ninguna sección de un fichero una vez ha sido escrita. Esto es más
jerojasro@410 133 robusto y eficiente que otros esquemas que requieren modificar o reescribir
jerojasro@410 134 datos.
jerojasro@410 135
jerojasro@410 136 Adicionalmente, Mercurial trata cada escritura como parte de una
jerojasro@410 137 \emph{transacción}, que puede cubrir varios ficheros. Una transacción es
jerojasro@410 138 \emph{atómica}: o bien la transacción tiene éxito y entonces todos sus efectos
jerojasro@410 139 son visibles para todos los lectores, o la operación completa es cancelada.
jerojasro@410 140 % TODO atomicidad no existe de acuerdo a DRAE, reemplazar
jerojasro@410 141 Esta garantía de atomicidad implica que, si usted está ejecutando dos copias de
jerojasro@410 142 Mercurial, donde una de ellas está leyendo datos y la otra los está escribiendo,
jerojasro@410 143 el lector nunca verá un resultado escrito parcialmente que podría confundirlo.
jerojasro@410 144
jerojasro@410 145 El hecho de que Mercurial sólo hace adiciones a los ficheros hace más fácil
jerojasro@410 146 proveer esta garantía transaccional. A medida que sea más fácil hacer
jerojasro@410 147 operaciones como ésta, más confianza tendrá usted en que sean hechas
jerojasro@410 148 correctamente.
jerojasro@410 149
jerojasro@410 150 \subsection{Recuperación rápida de datos}
jerojasro@410 151
jerojasro@410 152 Mercurial evita ingeniosamente un problema común a todos los sistemas de control
jerojasro@410 153 de revisiones anteriores> el problema de la
jerojasro@410 154 \emph{recuperación\ndt{\emph{Retrieval}. Recuperación en el sentido de traer los
jerojasro@410 155 datos, o reconstruirlos a partir de otros datos, pero no debido a una falla o
jerojasro@410 156 calamidad, sino a la operación normal del sistema.} ineficiente de datos}.
jerojasro@410 157 Muchos sistemas de control de revisiones almacenan los contenidos de una
jerojasro@410 158 revisión como una serie incremental de modificaciones a una ``instantánea''.
jerojasro@410 159 Para reconstruir una versión cualquiera, primero usted debe leer la instantánea,
jerojasro@410 160 y luego cada una de las revisiones entre la instantánea y su versión objetivo.
jerojasro@410 161 Entre más largo sea el historial de un fichero, más revisiones deben ser leídas,
jerojasro@410 162 y por tanto toma más tiempo reconstruir una versión particular.
jerojasro@343 163
jerojasro@343 164 \begin{figure}[ht]
jerojasro@343 165 \centering
jerojasro@343 166 \grafix{snapshot}
jerojasro@410 167 \caption{Instantánea de un revlog, con deltas incrementales}
jerojasro@343 168 \label{fig:concepts:snapshot}
jerojasro@343 169 \end{figure}
jerojasro@343 170
jerojasro@410 171 La innovación que aplica Mercurial a este problema es simple pero efectiva.
jerojasro@410 172 Una vez la cantidad de información de deltas acumulada desde la última
jerojasro@410 173 instantánea excede un umbral fijado de antemano, se almacena una nueva
jerojasro@410 174 instantánea (comprimida, por supuesto), en lugar de otro delta. Esto hace
jerojasro@410 175 posible reconstruir \emph{cualquier} versión de un fichero rápidamente. Este
jerojasro@410 176 enfoque funciona tan bien que desde entonces ha sido copiado por otros sistemas
jerojasro@410 177 de control de revisiones.
jerojasro@410 178
jerojasro@410 179 La figura~\ref{fig:concepts:snapshot} ilustra la idea. En una entrada en el
jerojasro@410 180 fichero índice de un revlog, Mercurial almacena el rango de entradas (deltas)
jerojasro@410 181 del fichero de datos que se deben leer para reconstruir una revisión en
jerojasro@410 182 particular.
jerojasro@410 183
jerojasro@410 184 \subsubsection{Nota al margen: la influencia de la compresión de vídeo}
jerojasro@410 185
jerojasro@410 186 Si le es familiar la compresión de vídeo, o ha mirado alguna vez una emisión de
jerojasro@410 187 TV a través de cable digital o un servicio de satélite, puede que sepa que la
jerojasro@410 188 mayor parte de los esquemas de compresión de vídeo almacenan cada cuadro del
jerojasro@410 189 mismo como un delta contra el cuadro predecesor. Adicionalmente, estos esquemas
jerojasro@411 190 usan técnicas de compresión ``con pérdida'' para aumentar la tasa de
jerojasro@410 191 compresión, por lo que los errores visuales se acumulan a lo largo de una
jerojasro@410 192 cantidad de deltas inter-cuadros.
jerojasro@343 193
jerojasro@415 194 Ya que existe la posibilidad de que un flujo de vídeo se ``pierda''
jerojasro@415 195 ocasionalmente debido a fallas en la señal, y para limitar la acumulación de
jerojasro@415 196 errores introducida por la compresión con pérdidas, los codificadores de vídeo
jerojasro@415 197 insertan periódicamente un cuadro completo (también llamado ``cuadro clave'') en
jerojasro@415 198 el flujo de vídeo; el siguiente delta es generado con respecto a dicho cuadro.
jerojasro@415 199 Esto quiere decir que si la señal de vídeo se interrumpe, se reanudará una vez
jerojasro@415 200 se reciba el siguiente cuadro clave. Además, la acumulación de errores de
jerojasro@415 201 codificación se reinicia con cada cuadro clave.
jerojasro@415 202
jerojasro@415 203 \subsection{Identificación e integridad fuerte}
jerojasro@415 204
jerojasro@416 205 Además de la información de deltas e instantáneas, una entrada en un
jerojasro@415 206 % TODO de pronto aclarar qué diablos es un hash?
jerojasro@416 207 revlog contiene un hash criptográfico de los datos que representa.
jerojasro@416 208 Esto hace difícil falsificar el contenido de una revisión, y hace
jerojasro@416 209 fácil detectar una corrupción accidental.
jerojasro@416 210
jerojasro@416 211 Los hashes proveen más que una simple revisión de corrupción: son
jerojasro@416 212 usados como los identificadores para las revisiones.
jerojasro@416 213 % TODO no entendí completamente la frase a continuación
jerojasro@416 214 Los hashes de
jerojasro@416 215 identificación de conjuntos de cambios que usted ve como usuario final
jerojasro@416 216 son de las revisiones de la bitácora de cambios. Aunque los ficheros
jerojasro@416 217 de registro y el manifiesto también usan hashes, Mercurial sólo los
jerojasro@416 218 usa tras bambalinas.
jerojasro@416 219
jerojasro@416 220 Mercurial verifica que los hashes sean correctos cuando recupera
jerojasro@416 221 revisiones de ficheros y cuando jala cambios desde otro repositorio.
jerojasro@416 222 Si se encuentra un problema de integridad, Mercurial se quejará y
jerojasro@416 223 detendrá cualquier operación que esté haciendo.
jerojasro@416 224
jerojasro@416 225 Además del efecto que tiene en la eficiencia en la recuperación, el
jerojasro@416 226 uso periódico de instantáneas de Mercurial lo hace más robusto frente
jerojasro@416 227 a la corrupción parcial de datos. Si un fichero de registro se
jerojasro@416 228 corrompe parcialmente debido a un error de hardware o del sistema, a
jerojasro@416 229 menudo es posible reconstruir algunas o la mayoría de las revisiones a
jerojasro@416 230 partir de las secciones no corrompidas del fichero de registro, tanto
jerojasro@416 231 antes como después de la sección corrompida. Esto no sería posible con
jerojasro@416 232 un sistema de almacenamiento basado únicamente en deltas.
jerojasro@343 233
jerojasro@418 234 \section{Historial de revisiones, ramas y fusiones}
jerojasro@418 235
jerojasro@418 236 Cada entrada en el revlog de Mercurial conoce la identidad de la
jerojasro@418 237 revisión de su ancestro inmediato, al que se conoce usualmente como su
jerojasro@418 238 \emph{padre}. De hecho, una revisión contiene sitio no sólo para un
jerojasro@418 239 padre, sino para dos. Mercurial usa un hash especial, llamado el
jerojasro@418 240 ``ID nulo'', para representar la idea de ``no hay padre aquí''. Este
jerojasro@418 241 hash es simplemente una cadena de ceros.
jerojasro@418 242
jerojasro@418 243 En la figura~\ref{fig:concepts:revlog} usted puede ver un ejemplo de
jerojasro@418 244 la estructura conceptual de un revlog. Los ficheros de registro,
jerojasro@418 245 manifiestos, y bitácoras de cambios comparten la misma estructura;
jerojasro@418 246 sólo difieren en el tipo de datos almacenados en cada delta o
jerojasro@418 247 instantánea.
jerojasro@418 248
jerojasro@418 249 La primera revisión en un revlog (al final de la imagen) tiene como
jerojasro@418 250 padre al ID nulo, en las dos ranuras disponibles para padres. En una
jerojasro@418 251 revisión normal, la primera ranura para padres contiene el ID de la
jerojasro@418 252 revisión padre, y la segunda contiene el ID nulo, señalando así que la
jerojasro@418 253 revisión sólo tiene un padre real. Un par de revisiones que tenga el
jerojasro@418 254 mismo ID padre son ramas. Una revisión que representa una fusión entre
jerojasro@418 255 ramas tiene dos IDs de revisión normales en sus ranuras para padres.
jerojasro@343 256
jerojasro@343 257 \begin{figure}[ht]
jerojasro@343 258 \centering
jerojasro@343 259 \grafix{revlog}
jerojasro@343 260 \caption{}
jerojasro@343 261 \label{fig:concepts:revlog}
jerojasro@343 262 \end{figure}
jerojasro@343 263
jerojasro@420 264 \section{El directorio de trabajo}
jerojasro@420 265
jerojasro@420 266 % TODO revisar párrafo, no me convence la traducción
jerojasro@420 267 En el directorio de trabajo, Mercurial almacena una instantánea de los
jerojasro@420 268 ficheros del repositorio como si fueran los de un conjunto de cambios
jerojasro@420 269 particular.
jerojasro@420 270
jerojasro@420 271 El directorio de trabajo ``sabe'' qué conjunto de cambios contiene.
jerojasro@420 272 Cuando usted actualiza el directorio de trabajo para que contenga un
jerojasro@420 273 conjunto de cambios particular, Mercurial busca la revisión adecuada
jerojasro@420 274 del manifiesto para averiguar qué ficheros estaba monitoreando cuando
jerojasro@420 275 se hizo la consignación del conjunto de cambios, y qué revisión de
jerojasro@420 276 cada fichero era la actual en ese momento. Luego de eso, recrea una
jerojasro@420 277 copia de cada uno de esos ficheros, con los mismos contenidos que
jerojasro@420 278 tenían cuando fue consignado el conjunto de cambios.
jerojasro@420 279
jerojasro@420 280 El \emph{estado de directorio}\ndt{dirstate, en inglés en el
jerojasro@420 281 original.} contiene el conocimiento de Mercurial acerca del directorio
jerojasro@420 282 de trabajo. Allí se detalla a qué conjunto de cambios es actualizado
jerojasro@420 283 el directorio de trabajo, y todos los ficheros que Mercurial está
jerojasro@420 284 monitoreando en este directorio.
jerojasro@420 285
jerojasro@420 286 Tal como la revisión de un revlog tiene espacio para dos padres, para
jerojasro@420 287 que pueda representar tanto una revisión normal (con un solo padre) o
jerojasro@420 288 una fusión de dos revisiones anteriores, el estado de directorio tiene
jerojasro@420 289 espacio para dos padres. Cuando usted usa el comando \hgcmd{update},
jerojasro@420 290 el conjunto de cambios al que usted se actualiza es almacenado en la
jerojasro@420 291 casilla destinada al ``primer padre'', y un ID nulo es almacenado en
jerojasro@420 292 la segunda. Cuando usted hace una fusión (\hgcmd{merge}) con otro
jerojasro@420 293 conjunto de cambios, la casilla para el primer padre permanece sin
jerojasro@420 294 cambios, y la casilla para el segundo es actualizada con el conjunto
jerojasro@420 295 de cambios con el que usted acaba de hacer la fusión. El comando
jerojasro@420 296 \hgcmd{parents} le indica cuáles son los padres del estado de
jerojasro@420 297 directorio.
jerojasro@420 298
jerojasro@420 299 \subsection{Qué pasa en una consignación}
jerojasro@420 300
jerojasro@420 301 El estado de directorio almacena información sobre los padres para
jerojasro@420 302 algo más que mero registro. Mercurial usa los padres del estado de
jerojasro@420 303 directorio como \emph{los padres de un nuevo conjunto de cambios}
jerojasro@420 304 cuando usted hace una consignación.
jerojasro@343 305
jerojasro@343 306 \begin{figure}[ht]
jerojasro@343 307 \centering
jerojasro@343 308 \grafix{wdir}
jerojasro@420 309 \caption{El directorio de trabajo puede tener dos padres}
jerojasro@343 310 \label{fig:concepts:wdir}
jerojasro@343 311 \end{figure}
jerojasro@343 312
jerojasro@420 313 La figura~\ref{fig:concepts:wdir} muestra el estado normal del
jerojasro@420 314 directorio de trabajo, que tiene un único conjunto de cambios como
jerojasro@420 315 padre. Dicho conjunto de cambios es la \emph{punta}, el conjunto de
jerojasro@420 316 cambios más reciente en el repositorio que no tiene hijos.
jerojasro@343 317
jerojasro@343 318 \begin{figure}[ht]
jerojasro@343 319 \centering
jerojasro@343 320 \grafix{wdir-after-commit}
jerojasro@420 321 \caption{El directorio de trabajo obtiene nuevos padres luego de una
jerojasro@420 322 consignación}
jerojasro@343 323 \label{fig:concepts:wdir-after-commit}
jerojasro@343 324 \end{figure}
jerojasro@343 325
jerojasro@420 326 Es útil pensar en el directorio de trabajo como en ``el conjunto de
jerojasro@420 327 cambios que estoy a punto de enviar''. Cualquier fichero que usted le
jerojasro@420 328 diga a Mercurial que fue añadido, borrado, renombrado o copiado, se
jerojasro@420 329 verá reflejado en ese conjunto de cambios, como también se verán las
jerojasro@420 330 modificaciones a cualquiera de los ficheros que Mercurial ya esté
jerojasro@420 331 monitoreando; el nuevo conjunto de cambios dentrá los padres del
jerojasro@420 332 directorio de trabajo como propios.
jerojasro@420 333
jerojasro@420 334 Luego de una consignación, Mercurial actualizará los padres del
jerojasro@420 335 directorio de trabajo, de tal manera que el primer padre sea el ID del
jerojasro@420 336 nuevo conjunto de cambios, y el segundo sea el ID nulo. Esto puede
jerojasro@420 337 verse en la figura~\ref{fig:concepts:wdir-after-commit}. Mercurial no
jerojasro@420 338 toca ninguno de los ficheros del directorio de trabajo cuando usted
jerojasro@420 339 hace la consignación; sólo modifica el estado de directorio para
jerojasro@420 340 anotar sus nuevos padres.
jerojasro@343 341
jerojasro@422 342 \subsection{Creación de un nuevo frente}
jerojasro@422 343
jerojasro@422 344 Es perfectamente normal actualizar el directorio de trabajo a un
jerojasro@422 345 conjunto de cambios diferente a la punta actual. Por ejemplo, usted
jerojasro@422 346 podría desear saber en qué estado se encontraba su proyecto el martes
jerojasro@422 347 pasado, o podría estar buscando en todos los conjuntos de cambios para
jerojasro@422 348 saber cuándo se introdujo un fallo. En casos como éstos, la acción
jerojasro@422 349 natural es actualizar el directorio de trabajo al conjunto de cambios
jerojasro@422 350 de su interés, y examinar directamente los ficheros en el directorio
jerojasro@422 351 de trabajo para ver sus contenidos tal como estaban en el momento de
jerojasro@422 352 hacer la consignación. El efecto que tiene esto se muestra en la
jerojasro@422 353 figura~\ref{fig:concepts:wdir-pre-branch}.
jerojasro@343 354
jerojasro@343 355 \begin{figure}[ht]
jerojasro@343 356 \centering
jerojasro@343 357 \grafix{wdir-pre-branch}
jerojasro@422 358 \caption{El directorio de trabajo, actualizado a un conjunto de
jerojasro@422 359 cambios anterior}
jerojasro@343 360 \label{fig:concepts:wdir-pre-branch}
jerojasro@343 361 \end{figure}
jerojasro@343 362
jerojasro@422 363 Una vez se ha actualizado el directorio de trabajo a un conjunto de
jerojasro@422 364 cambios anterior, qué pasa si se hacen cambios, y luego se hace una
jerojasro@422 365 consignación? Mercurial se comporta en la misma forma que describí
jerojasro@422 366 anteriormente. Los padres del directorio de trabajo se convierten en
jerojasro@422 367 los padres del nuevo conjunto de cambios. Este nuevo conjunto de
jerojasro@422 368 cambios no tiene hijos, así que se convierte en la nueva punta. Y el
jerojasro@422 369 repositorio tiene ahora dos conjuntos de cambios que no tienen hijos;
jerojasro@422 370 a éstos los llamamos \emph{frentes}. Usted puede apreciar la
jerojasro@422 371 estructura que esto crea en la figura~\ref{fig:concepts:wdir-branch}.
jerojasro@343 372
jerojasro@343 373 \begin{figure}[ht]
jerojasro@343 374 \centering
jerojasro@343 375 \grafix{wdir-branch}
jerojasro@422 376 \caption{Después de una consignación hecha mientras se usaba un
jerojasro@422 377 conjunto de cambios anterior}
jerojasro@343 378 \label{fig:concepts:wdir-branch}
jerojasro@343 379 \end{figure}
jerojasro@343 380
jerojasro@343 381 \begin{note}
jerojasro@422 382 Si usted es nuevo en Mercurial, debería tener en mente un
jerojasro@422 383 ``error'' común, que es usar el comando \hgcmd{pull} sin ninguna
jerojasro@422 384 opción. Por defecto, el comando \hgcmd{pull} \emph{no} actualiza
jerojasro@422 385 el directorio de trabajo, así que usted termina trayendo nuevos
jerojasro@422 386 conjuntos de cambios a su repositorio, pero el directorio de
jerojasro@422 387 trabajo sigue usando el mismo conjunto de cambios que tenía antes
jerojasro@422 388 de jalar. Si usted hace algunos cambios, y luego hace una
jerojasro@422 389 consignación, estará creando un nuevo frente, porque su directorio
jerojasro@422 390 de trabajo no es sincronizado a cualquiera que sea la nueva punta.
jerojasro@422 391
jerojasro@422 392 Pongo la palabra ``error'' en comillas porque todo lo que usted
jerojasro@422 393 debe hacer para rectificar la situación es hacer una fusión
jerojasro@422 394 (\hgcmd{merge}), y luego una consignación (\hgcmd{commit}). En
jerojasro@422 395 otras palabras, esto casi nunca tiene consecuencias negativas;
jerojasro@422 396 sólo sorprende a la gente. Discutiré otras formas de evitar este
jerojasro@422 397 comportamiento, y porqué Mercurial se comporta de esta forma,
jerojasro@422 398 inicialmente sorprendente, más adelante.
jerojasro@343 399 \end{note}
jerojasro@343 400
jerojasro@422 401 \subsection{Fusión de frentes}
jerojasro@422 402
jerojasro@422 403 Cuando usted ejecuta el comando \hgcmd{merge}, Mercurial deja el
jerojasro@422 404 primer padre del directorio de trabajo intacto, y escribe como segundo
jerojasro@422 405 padre el conjunto de cambios contra el cual usted está haciendo la
jerojasro@422 406 fusión, como se muestra en la figura~\ref{fig:concepts:wdir-merge}.
jerojasro@343 407
jerojasro@343 408 \begin{figure}[ht]
jerojasro@343 409 \centering
jerojasro@343 410 \grafix{wdir-merge}
jerojasro@422 411 \caption{Fusión de dos frentes}
jerojasro@343 412 \label{fig:concepts:wdir-merge}
jerojasro@343 413 \end{figure}
jerojasro@343 414
jerojasro@422 415 Mercurial también debe modificar el directorio de trabajo, para
jerojasro@422 416 fusionar los ficheros que él monitorea en los dos conjuntos de
jerojasro@422 417 cambios. Con algunas simplificaciones, el proceso es el siguiente, por
jerojasro@422 418 cada fichero en los manifiestos de ambos conjuntos de cambios.
jerojasro@343 419 \begin{itemize}
jerojasro@422 420 \item Si ningún conjunto de cambios ha modificado un fichero, no se
jerojasro@422 421 hace nada con el mismo.
jerojasro@422 422 \item Si un conjunto de cambios ha modificado un fichero, y el otro no
jerojasro@422 423 lo ha hecho, se crea una copia del fichero con las modificaciones
jerojasro@422 424 pertinentes en el directorio de trabajo.
jerojasro@422 425 \item Si un conjunto de cambios borra un fichero, y el otro no lo ha
jerojasro@422 426 hecho (o también lo borró), se borra dicho fichero del directorio
jerojasro@422 427 de trabajo.
jerojasro@422 428 \item Si un conjunto de cambios ha borrado un fichero, pero el otro lo ha
jerojasro@422 429 modificado, se le pregunta al usuario qué hacer: conservar el
jerojasro@422 430 fichero modificado, o borrarlo?
jerojasro@422 431 \item Si ambos conjuntos de cambios han modificado un fichero, se
jerojasro@422 432 invoca el programa externo de fusión para definir el nuevo
jerojasro@422 433 contenido del fichero fusionado. Esto puede requerir interacción
jerojasro@422 434 directa de parte del usuario.
jerojasro@422 435 \item Si un conjunto de cambios ha modificado un fichero, y el otro ha
jerojasro@422 436 renombrado o copiado el mismo, asegurarse de que los cambios sigan
jerojasro@422 437 al nuevo nombre de fichero.
jerojasro@343 438 \end{itemize}
jerojasro@422 439 Hay más detalles---hacer una fusión tiene una gran cantidad de casos
jerojasro@422 440 especiales---pero éstas son las elecciones más comunes que se ven
jerojasro@422 441 involucradas en una fusión. Como usted puede ver, muchos de los casos
jerojasro@422 442 son completamente automáticos, y de hecho la mayoría de las fusiones
jerojasro@422 443 terminan automáticamente, sin requerir la interacción del usuario para
jerojasro@422 444 resolver ningún conflicto.
jerojasro@343 445
jerojasro@423 446 Cuando considere qué pasa cuando usted hace una consignación después
jerojasro@423 447 de una fusión, de nuevo el directorio de trabajo es ``el conjunto de
jerojasro@423 448 cambios que estoy a punto de consignar''. Una vez termina su trabajo
jerojasro@423 449 el comando \hgcmd{merge}, el directorio de trabajo tiene dos padre;
jerojasro@423 450 éstos se convertirán en los padres del nuevo conjunto de cambios.
jerojasro@423 451
jerojasro@423 452 Mercurial le permite hacer múltiples fusiones, pero usted debe
jerojasro@423 453 consignar los resultados de cada fusión sucesivamente. Esto es
jerojasro@423 454 necesario porque Mercurial sólo monitorea dos padres, tanto para las
jerojasro@423 455 revisiones como para los directorios de trabajo. Aunque técnicamente
jerojasro@423 456 es posible fusionar varios conjuntos de trabajo en una sola operación,
jerojasro@423 457 la posibilidad de confundir al usuario y crear un desorden terrible en
jerojasro@423 458 la fusión se hace incontenible de inmediato.
jerojasro@423 459
jerojasro@423 460 \section{Otras características de diseño interesantes}
jerojasro@423 461
jerojasro@423 462 En las secciones anteriores, he tratado de resaltar algunos de los
jerojasro@423 463 aspectos más importantes del diseño de Mercurial, para mostrar que se
jerojasro@423 464 presta gran cuidado y atención a la confiabilidad y el desempeño. Sin
jerojasro@423 465 embargo, la atención a los detalles no para ahí. Hay una cantidad de
jerojasro@423 466 aspectos de la construcción de Mercurial que encuentro interesantes
jerojasro@423 467 personalmente. Detallaré unos cuantos de ellos aquí, aparte de los
jerojasro@423 468 elementos ``importantes'' de arriba, para que, si usted está
jerojasro@423 469 % TODO the amount of thinking => (la cantidad de) esfuerzo mental
jerojasro@423 470 interesado, pueda obetener una idea mejor de la cantidad de esfuerzo
jerojasro@423 471 mental invertido en el diseño de un sistema bien diseñado.
jerojasro@423 472
jerojasro@423 473
jerojasro@423 474 \subsection{Compresión ingeniosa}
jerojasro@423 475
jerojasro@423 476 Cuando es adecuado, Mercurial almacenará tanto las instantáneas como
jerojasro@423 477 los deltas en formato comprimido. Lo hace \emph{tratando} siempre de
jerojasro@423 478 comprimir una instantánea o delta, y conservando la versión comprimida
jerojasro@423 479 sólo si es más pequeña que la versión sin compresión.
jerojasro@423 480
jerojasro@423 481 Esto implica que Mercurial hace ``lo correcto'' cuando almacena un
jerojasro@423 482 fichero cuyo formato original está comprimido, como un fichero
jerojasro@423 483 \texttt{zip} o una imagen JPEG. Cuando estos tipos de ficheros son
jerojasro@423 484 comprimidos por segunda vez, el fichero resultante usualmente es más
jerojasro@423 485 grande que la versión comprimida una sola vez, por lo que Mercurial
jerojasro@423 486 almacenará el fichero \texttt{zip} o JPEG original.
jerojasro@423 487
jerojasro@423 488 Los deltas entre revisiones de un fichero comprimido usualmente son
jerojasro@423 489 más grandes que las instantáneas del mismo fichero, y Mercurial de
jerojasro@423 490 nuevo hace ``lo correcto'' en estos casos. Él encuentra que dicho
jerojasro@423 491 delta excede el umbral respecto al cual se debería almacenar una
jerojasro@423 492 instantánea completa del fichero, así que almacena la instantánea,
jerojasro@423 493 ahorrando espacio de nuevo respecto al enfoque simplista de usar
jerojasro@423 494 únicamente deltas.
jerojasro@423 495
jerojasro@423 496 \subsubsection{Recompresión de red}
jerojasro@423 497
jerojasro@423 498 Cuando almacena las revisiones en disco, Mercurial usa el algoritmo de
jerojasro@423 499 compresión ``deflación'' (el mismo usado en el popular formato de
jerojasro@423 500 fichero \texttt{zip}), que provee una buena velocidad con una tasa de
jerojasro@423 501 compresión respetable. Sin embargo, cuando se transmiten datos de
jerojasro@423 502 revisiones a través de una conexión de red, Mercurial descomprime los
jerojasro@423 503 datos comprimidos de las revisiones.
jerojasro@423 504
jerojasro@423 505 Si la conexión es hecha a través de HTTP, Mercurial recomprime el
jerojasro@423 506 flujo completo de datos usando un algoritmo de compresión que brinda
jerojasro@517 507 una mejor tasa de compresión (el algoritmo Burrows-Wheeler del
jerojasro@423 508 ampliamente usado paquete de compresión \texttt{bzip2}). Esta
jerojasro@423 509 combinación de algoritmo y compresión del flujo completo de datos
jerojasro@423 510 (en vez de una revisión a la vez) reduce sustancialmente la cantidad
jerojasro@423 511 de bytes a transferir, brindando así un mejor desempeño de red sobre
jerojasro@423 512 casi todo tipo de redes.
jerojasro@423 513
jerojasro@423 514 (Si la conexión se hace sobre \command{ssh}, Mercurial \emph{no}
jerojasro@423 515 recomprmime el flujo, porque \command{ssh} puede hacer esto por sí
jerojasro@423 516 mismo.)
jerojasro@343 517
jerojasro@424 518 \subsection{Reordenado de lectura/escritura y atomicidad}
jerojasro@424 519
jerojasro@424 520 Añadir datos al final de un fichero no es todo lo que hace falta para
jerojasro@424 521 garantizar que un lector no verá una escritura parcial. Si recuerda la
jerojasro@424 522 figura~\ref{fig:concepts:metadata}, las revisiones en la bitácora de
jerojasro@424 523 cambios apuntan a revisiones en el manifiesto, y las revisiones en el
jerojasro@424 524 manifiesto apuntan a revisiones en ficheros de registro. Esta
jerojasro@424 525 jerarquía es deliberada.
jerojasro@424 526
jerojasro@424 527 Un escritor inicia una transacción al escribir los datos del ficheros
jerojasro@424 528 del fichero de registro y el manifiesto, y no escribe nada en la
jerojasro@424 529 bitácora de cambios hasta que dichas escrituras hayan terminado. Un
jerojasro@424 530 lector empieza leyendo datos de la bitácora de cambios, luego del
jerojasro@424 531 manifiesto, y finalmente del fichero de registro.
jerojasro@343 532
jerojasro@425 533 %TODO revisar párrafo completo, no me gusta el resultado
jerojasro@425 534 Como el escritor siempre termina de escribir los datos en el fichero
jerojasro@425 535 de registro y en el manifiesto antes de escribir a la bitácora de
jerojasro@425 536 cambios, un lector nunca verá un apuntador a una versión parcialmente
jerojasro@425 537 escrita de revisiones del manifiesto desde la bitácora de cambios, y
jerojasro@425 538 nunca leerá un apuntador a una revisión parcialmente escrita del
jerojasro@425 539 fichero de registro desde el manifiesto.
jerojasro@425 540
jerojasro@425 541 \subsection{Acceso concurrente}
jerojasro@425 542
jerojasro@425 543 El reordenado de lectura/escritura y la atomicidad garantizan que
jerojasro@425 544 Mercurial nunca necesita \emph{bloquear} un repositorio cuando está
jerojasro@425 545 leyendo datos, aún si se está escribiendo al repositorio mientras se
jerojasro@425 546 hace la lectura. Esto tiene un gran efecto en la escalabilidad; usted
jerojasro@425 547 puede tener cualquier cantidad de procesos Mercurial leyendo datos de
jerojasro@425 548 un repositorio de manera segura al mismo tiempo, sin importar si se
jerojasro@425 549 está escribiendo al mismo o no.
jerojasro@425 550
jerojasro@425 551 La naturaleza carente de bloqueos de la lectura significa que si usted
jerojasro@426 552 está compartiendo un repositorio en un sistema multiusuario, no
jerojasro@426 553 necesita dar a los usuarios locales permisos de \emph{escritura} a su
jerojasro@426 554 repositorio para que ellos puedan clonarlo o jalar cambios; sólo
jerojasro@426 555 necesitan permisos de \emph{lectura}. (Esta \emph{no} es una
jerojasro@426 556 %TODO signo de admiración de apertura
jerojasro@426 557 característica común entre los sistemas de control de revisiones, así
jerojasro@426 558 que no la dé por hecha! Muchos de ellos requieren que los lectores
jerojasro@426 559 sean capaces de bloquear el repositorio antes de poder leerlo, y esto
jerojasro@426 560 requiere acceso de escritura en al menos un directorio, lo que por
jerojasro@426 561 supuesto se convierte en una fuente de todo tipo de problemas
jerojasro@426 562 administrativos y de seguridad bastante molestos.)
jerojasro@426 563
jerojasro@426 564 Mercurial usar bloqueos para asegurarse de que sólo un proceso pueda
jerojasro@426 565 escribir a un repositorio al mismo tiempo (el mecanismo de bloqueo es
jerojasro@516 566 seguro incluso sobre sistemas de ficheros notoriamente hostiles al
jerojasro@426 567 bloqueo, como NFS). Si un repositorio está bloqueado, los escritores
jerojasro@426 568 esperarán un buen rato para revisar si el repositorio ya ha sido
jerojasro@426 569 desbloqueado, pero si el repositorio sique bloqueado por mucho tiempo,
jerojasro@426 570 el proceso que intenta escribir fallará por tiempo de espera máximo.
jerojasro@426 571 Esto significa que sus guiones automáticos diarios no se quedarán
jerojasro@426 572 esperando para siempre, apilándose si el sistema se cayó sin que nadie
jerojasro@426 573 se diera cuenta, por ejemplo. (Sí, el tiempo de espera máximo es
jerojasro@426 574 configurable, de cero a infinito).
jerojasro@426 575
jerojasro@426 576
jerojasro@426 577 \subsubsection{Acceso seguro al estado de directorio}
jerojasro@426 578
jerojasro@426 579 Al igual que con los datos de revisión, Mercurial no requiere un
jerojasro@426 580 bloqueo para leer el fichero de estado de directorio; sí se usa un
jerojasro@426 581 bloqueo para escribir a él. Para evitar la posibilidad de leer una
jerojasro@426 582 copia parcialmente escrita del fichero de estado de directorio,
jerojasro@426 583 Mercurial escribe a un fichero con un nombre único en el mismo
jerojasro@426 584 directorio del fichero de estado de directorio, y luego renombra
jerojasro@426 585 atómicamente este fichero temporal a \filename{dirstate}\ndt{Estado de
jerojasro@426 586 directorio.}. Así se garantiza que el fichero llamado
jerojasro@426 587 \filename{dirstate} esté completo, y no parcialmente escrito.
jerojasro@426 588
jerojasro@426 589 \subsection{Evitar movimientos de brazo}
jerojasro@426 590
jerojasro@426 591 Un aspecto crítico para el desempeño de Mercurial es evitar los
jerojasro@426 592 movimientos del brazo de lectura del disco duro, ya que cualquier
jerojasro@426 593 movimiento de brazo es mucho más costoso que incluso una operación de
jerojasro@426 594 lectura relativamente grande.
jerojasro@426 595
jerojasro@426 596 Es por esto que, por ejemplo, el estado de directorio es almacenado
jerojasro@426 597 como un solo fichero. Si hubiera un estado de directorio por cada
jerojasro@426 598 directorio que Mercurial monitorea, el disco haría un movimiento de
jerojasro@426 599 brazo por cada directorio. En cambio, Mercurial lee el estado de
jerojasro@426 600 directorio completo en un solo paso.
jerojasro@426 601
jerojasro@426 602 Mercurial también usa un esquema de ``copiar al escribir'' cuando
jerojasro@426 603 clona un repositorio en un mismo medio de almacenamiento local. En vez
jerojasro@426 604 de copiar cada fichero de revlog del repositorio viejo al nuevo, se
jerojasro@426 605 crea un ``enlace duro'', que es una manera sucinta de decir
jerojasro@426 606 ``estos dos nombres apuntan al mismo fichero''. Cuando Mercurial está
jerojasro@426 607 a punto de escribir a uno de los ficheros de revlog, revisa si la
jerojasro@426 608 cantidad de nombres apuntando al fichero es de más de uno. Si lo es,
jerojasro@426 609 más de un repositorio está usando el fichero, así que Mercurial hace
jerojasro@426 610 una nueva copia del fichero, privada para este repositorio.
jerojasro@426 611
jerojasro@426 612 Algunos desarrolladores de control de revisiones han indicado que la
jerojasro@426 613 idea de hacer una copia privada completa de un fichero no es eficiente
jerojasro@426 614 desde el punto de vista de almacenamiento. Aunque esto es cierto, el
jerojasro@426 615 almacenamiento es barato, y este método brinda el máximo rendimiento
jerojasro@426 616 al tiempo que delega la mayor parte del trabajo de manejo de ficheros
jerojasro@426 617 al sistema operativo. Un esquema alternativo seguramente reduciría el
jerojasro@426 618 desempeño y aumentaría la complejidad del software, cada uno de los
jerojasro@426 619 cuales es mucho más importante para la ``sensación'' que se tiene del
jerojasro@426 620 software en el trabajo día a día.
jerojasro@426 621
jerojasro@426 622 \subsection{Otros contenidos del estado de directorio}
jerojasro@426 623
jerojasro@426 624 Debido a que Mercurial no lo fuerza a indicar si usted está
jerojasro@426 625 modificando un fichero, se usa el estado de directorio para almacenar
jerojasro@426 626 información extra para poder determinar efecientemente si usted ha
jerojasro@426 627 modificado un fichero. Por cada fichero en el directorio de trabajo,
jerojasro@426 628 se almacena el momento en que Mercurial modificó por última vez el
jerojasro@426 629 fichero, y el tamaño del fichero en ese momento.
jerojasro@426 630
jerojasro@525 631 Cuando usted añade (\hgcmd{add}), remueve (\hgcmd{remove}), renombra
jerojasro@426 632 (\hgcmd{rename}) o copia (\hgcmd{copy}) ficheros, Mercurial actualiza
jerojasro@426 633 el estado de directorio para saber qué hacer con dichos ficheros
jerojasro@426 634 cuando usted haga la consignación.
jerojasro@426 635
jerojasro@426 636 Cuando Mercurial está revisando el estado de los ficheros en el
jerojasro@426 637 directorio de trabajo, revisa primero la fecha de modificación del
jerojasro@426 638 fichero. Si no ha cambiado, el fichero no ha sido modificado. Si el
jerojasro@426 639 tamaño del fichero ha cambiado, el fichero ha sido modificado. Sólo en
jerojasro@426 640 el caso en que el tiempo de modificación ha cambiado, pero el tamaño
jerojasro@426 641 no, es necesario leer el contenido del fichero para revisar si ha
jerojasro@426 642 cambiado. Almacenar estos pocos datos reduce dramáticamente la
jerojasro@426 643 cantidad de datos que Mercurial debe leer, lo que brinda una mejora en
jerojasro@426 644 el rendimiento grande, comparado con otros sistemas de control de
jerojasro@426 645 revisiones.
jerojasro@343 646
jerojasro@343 647 %%% Local Variables:
jerojasro@343 648 %%% mode: latex
jerojasro@343 649 %%% TeX-master: "00book"
jerojasro@343 650 %%% End: