hgbook

annotate es/concepts.tex @ 890:2887b61fa4fe

find changesets by author, revision, files, or words in the commit message
Change fields to fieldsets in the Comment admin model. The 'date'
field isn't working properly for an unknown reason, so it has been
removed from the interface temporarily.
author dukebody <dukebody@gmail.com>
date Sun Oct 11 21:12:46 2009 +0200 (2009-10-11)
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: