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:
|