hgbook
annotate es/concepts.tex @ 1114:527b86d55d4a
inotify: update installation information
inotify is shipped in Mercurial since 1.0, which greatly simplifies the installation process
inotify is shipped in Mercurial since 1.0, which greatly simplifies the installation process
author | Nicolas Dumazet <nicdumz.commits@gmail.com> |
---|---|
date | Sun Dec 13 16:35:56 2009 +0900 (2009-12-13) |
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: |