hgbook
view es/concepts.tex @ 416:15bf7d50b586
Translated a couple of paragraphs
| author | jerojasro@devnull.li |
|---|---|
| date | Wed Nov 12 22:36:35 2008 -0500 (2008-11-12) |
| parents | 0eda2936ef77 |
| children | bc2136732cd6 |
line source
1 \chapter{Tras bambalinas}
2 \label{chap:concepts}
4 A diferencia de varios sistemas de control de revisiones, los
5 conceptos en los que se fundamenta Mercurial son lo suficientemente
6 simples como para entender fácilmente cómo funciona el software.
7 Saber esto no es necesario, pero considero útil tener un ``modelo
8 mental'' de qué es lo que sucede.
10 Comprender esto me da la confianza de que Mercurial ha sido
11 cuidadosamente diseñado para ser tanto \emph{seguro} como
12 \emph{eficiente}. Y tal vez con la misma importancia, si es fácil
13 para mí hacerme a una idea adecuada de qué está haciendo el software
14 cuando llevo a cabo una tarea relacionada con control de revisiones,
15 es menos probable que me sosprenda su comportamiento.
17 En este capítulo, cubriremos inicialmente los conceptos centrales
18 del diseño de Mercurial, y luego discutiremos algunos detalles
19 interesantes de su implementación.
21 \section{Registro del historial de Mercurial}
23 \subsection{Seguir el historial de un único fichero}
25 Cuando Mercurial sigue las modificaciones a un fichero, guarda el
26 historial de dicho fichero en un objeto de metadatos llamado
27 \emph{filelog}\ndt{Fichero de registro}. Cada entrada en el fichero
28 de registro contiene suficiente información para reconstruir una
29 revisión del fichero que se está siguiendo. Los ficheros de registro
30 son almacenados como ficheros el el directorio
31 \sdirname{.hg/store/data}. Un fichero de registro contiene dos tipos
32 de información: datos de revisiones, y un índice para ayudar a
33 Mercurial a buscar revisiones eficientemente.
35 El fichero de registro de un fichero grande, o con un historial muy
36 largo, es guardado como ficheros separados para datos (sufijo
37 ``\texttt{.d}'') y para el índice (sufijo ``\texttt{.i}''). Para
38 ficheros pequeños con un historial pequeño, los datos de revisiones y
39 el índice son combinados en un único fichero ``\texttt{.i}''. La
40 correspondencia entre un fichero en el directorio de trabajo y el
41 fichero de registro que hace seguimiento a su historial en el
42 repositorio se ilustra en la figura~\ref{fig:concepts:filelog}.
44 \begin{figure}[ht]
45 \centering
46 \grafix{filelog}
47 \caption{Relación entre ficheros en el directorio de trabajo y
48 ficheros de registro en el repositorio}
49 \label{fig:concepts:filelog}
50 \end{figure}
52 \subsection{Administración de ficheros monitoreados}
54 Mercurial usa una estructura llamada \emph{manifiesto} para
55 % TODO collect together => centralizar
56 centralizar la información que maneja acerca de los ficheros que
57 monitorea. Cada entrada en el manifiesto contiene información acerca
58 de los ficheros involucrados en un único conjunto de cambios. Una
59 entrada registra qué ficheros están presentes en el conjunto de
60 cambios, la revisión de cada fichero, y otros cuantos metadatos del
61 mismo.
63 \subsection{Registro de información del conjunto de cambios}
65 La \emph{bitácora de cambios} contiene información acerca de cada
66 conjunto de cambios. Cada revisión indica quién consignó un cambio, el
67 comentario para el conjunto de cambios, otros datos relacionados con
68 el conjunto de cambios, y la revisión del manifiesto a usar.
70 \subsection{Relaciones entre revisiones}
72 Dentro de una bitácora de cambios, un manifiesto, o un fichero de
73 registro, cada revisión conserva un apuntador a su padre inmediato
74 (o sus dos padres, si es la revisión de una fusión). Como menciońe
75 anteriormente, también hay relaciones entre revisiones \emph{a través}
76 de estas estructuras, y tienen naturaleza jerárquica.
78 Por cada conjunto de cambios en un repositorio, hay exactamente una
79 revisión almacenada en la bitácora de cambios. Cada revisión de la
80 bitácora de cambios contiene un apuntador a una única revisión del
81 manifiesto. Una revisión del manifiesto almacena un apuntador a una
82 única revisión de cada fichero de registro al que se le hacía
83 seguimiento cuando fue creado el conjunto de cambios. Estas relaciones
84 se ilustran en la figura~\ref{fig:concepts:metadata}.
86 \begin{figure}[ht]
87 \centering
88 \grafix{metadata}
89 \caption{Relaciones entre metadatos}
90 \label{fig:concepts:metadata}
91 \end{figure}
93 Como lo muestra la figura, \emph{no} hay una relación ``uno a uno''
94 entre las revisiones en el conjunto de cambios, el manifiesto, o el
95 fichero de registro. Si el manifiesto no ha sido modificado de un
96 conjunto de cambios a otro, las entradas en la bitácora de cambios
97 para esos conjuntos de cambios apuntarán a la misma revisión del
98 manifiesto. Si un fichero monitoreado por Mercurial no sufre ningún
99 cambio de un conjunto de cambios a otro, la entrada para dicho fichero
100 en las dos revisiones del manifiesto apuntará a la misma revisión de
101 su fichero de registro.
103 \section{Almacenamiento seguro y eficiente}
105 La base común de las bitácoras de cambios, los manifiestos, y los
106 ficheros de registros es provista por una única estructura llamada el
107 \emph{revlog}\ndt{Contracción de \emph{revision log}, registro de
108 revisión.}.
110 \subsection{Almacenamiento eficiente}
112 El revlog provee almacenamiento eficiente de revisiones por medio del
113 mecanismo de \emph{deltas}\ndt{Diferencias.}. En vez de almacenar una
114 copia completa del fichero por cada revisión, almacena los cambios
115 necesarios para transformar una revisión anterior en la nueva
116 revisión. Para muchos tipos de fichero, estos deltas son típicamente
117 de una fracción porcentual del tamaño de una copia completa del
118 fichero.
120 Algunos sistemas de control de revisiones obsoletos sólo pueden
121 manipular deltas de ficheros de texto plano. Ellos o bien almacenan
122 los ficheros binarios como instantáneas completas, o codificados en
123 alguna representación de texto plano adecuada, y ambas alternativas
124 son enfoques que desperdician bastantes recursos. Mercurial puede
125 manejar deltas de ficheros con contenido binario arbitrario; no
126 necesita tratar el texto plano como un caso especial.
128 \subsection{Operación segura}
129 \label{sec:concepts:txn}
131 Mercurial sólo \emph{añade} datos al final de los ficheros de revlog. Nunca
132 modifica ninguna sección de un fichero una vez ha sido escrita. Esto es más
133 robusto y eficiente que otros esquemas que requieren modificar o reescribir
134 datos.
136 Adicionalmente, Mercurial trata cada escritura como parte de una
137 \emph{transacción}, que puede cubrir varios ficheros. Una transacción es
138 \emph{atómica}: o bien la transacción tiene éxito y entonces todos sus efectos
139 son visibles para todos los lectores, o la operación completa es cancelada.
140 % TODO atomicidad no existe de acuerdo a DRAE, reemplazar
141 Esta garantía de atomicidad implica que, si usted está ejecutando dos copias de
142 Mercurial, donde una de ellas está leyendo datos y la otra los está escribiendo,
143 el lector nunca verá un resultado escrito parcialmente que podría confundirlo.
145 El hecho de que Mercurial sólo hace adiciones a los ficheros hace más fácil
146 proveer esta garantía transaccional. A medida que sea más fácil hacer
147 operaciones como ésta, más confianza tendrá usted en que sean hechas
148 correctamente.
150 \subsection{Recuperación rápida de datos}
152 Mercurial evita ingeniosamente un problema común a todos los sistemas de control
153 de revisiones anteriores> el problema de la
154 \emph{recuperación\ndt{\emph{Retrieval}. Recuperación en el sentido de traer los
155 datos, o reconstruirlos a partir de otros datos, pero no debido a una falla o
156 calamidad, sino a la operación normal del sistema.} ineficiente de datos}.
157 Muchos sistemas de control de revisiones almacenan los contenidos de una
158 revisión como una serie incremental de modificaciones a una ``instantánea''.
159 Para reconstruir una versión cualquiera, primero usted debe leer la instantánea,
160 y luego cada una de las revisiones entre la instantánea y su versión objetivo.
161 Entre más largo sea el historial de un fichero, más revisiones deben ser leídas,
162 y por tanto toma más tiempo reconstruir una versión particular.
164 \begin{figure}[ht]
165 \centering
166 \grafix{snapshot}
167 \caption{Instantánea de un revlog, con deltas incrementales}
168 \label{fig:concepts:snapshot}
169 \end{figure}
171 La innovación que aplica Mercurial a este problema es simple pero efectiva.
172 Una vez la cantidad de información de deltas acumulada desde la última
173 instantánea excede un umbral fijado de antemano, se almacena una nueva
174 instantánea (comprimida, por supuesto), en lugar de otro delta. Esto hace
175 posible reconstruir \emph{cualquier} versión de un fichero rápidamente. Este
176 enfoque funciona tan bien que desde entonces ha sido copiado por otros sistemas
177 de control de revisiones.
179 La figura~\ref{fig:concepts:snapshot} ilustra la idea. En una entrada en el
180 fichero índice de un revlog, Mercurial almacena el rango de entradas (deltas)
181 del fichero de datos que se deben leer para reconstruir una revisión en
182 particular.
184 \subsubsection{Nota al margen: la influencia de la compresión de vídeo}
186 Si le es familiar la compresión de vídeo, o ha mirado alguna vez una emisión de
187 TV a través de cable digital o un servicio de satélite, puede que sepa que la
188 mayor parte de los esquemas de compresión de vídeo almacenan cada cuadro del
189 mismo como un delta contra el cuadro predecesor. Adicionalmente, estos esquemas
190 usan técnicas de compresión ``con pérdida'' para aumentar la tasa de
191 compresión, por lo que los errores visuales se acumulan a lo largo de una
192 cantidad de deltas inter-cuadros.
194 Ya que existe la posibilidad de que un flujo de vídeo se ``pierda''
195 ocasionalmente debido a fallas en la señal, y para limitar la acumulación de
196 errores introducida por la compresión con pérdidas, los codificadores de vídeo
197 insertan periódicamente un cuadro completo (también llamado ``cuadro clave'') en
198 el flujo de vídeo; el siguiente delta es generado con respecto a dicho cuadro.
199 Esto quiere decir que si la señal de vídeo se interrumpe, se reanudará una vez
200 se reciba el siguiente cuadro clave. Además, la acumulación de errores de
201 codificación se reinicia con cada cuadro clave.
203 \subsection{Identificación e integridad fuerte}
205 Además de la información de deltas e instantáneas, una entrada en un
206 % TODO de pronto aclarar qué diablos es un hash?
207 revlog contiene un hash criptográfico de los datos que representa.
208 Esto hace difícil falsificar el contenido de una revisión, y hace
209 fácil detectar una corrupción accidental.
211 Los hashes proveen más que una simple revisión de corrupción: son
212 usados como los identificadores para las revisiones.
213 % TODO no entendí completamente la frase a continuación
214 Los hashes de
215 identificación de conjuntos de cambios que usted ve como usuario final
216 son de las revisiones de la bitácora de cambios. Aunque los ficheros
217 de registro y el manifiesto también usan hashes, Mercurial sólo los
218 usa tras bambalinas.
220 Mercurial verifica que los hashes sean correctos cuando recupera
221 revisiones de ficheros y cuando jala cambios desde otro repositorio.
222 Si se encuentra un problema de integridad, Mercurial se quejará y
223 detendrá cualquier operación que esté haciendo.
225 Además del efecto que tiene en la eficiencia en la recuperación, el
226 uso periódico de instantáneas de Mercurial lo hace más robusto frente
227 a la corrupción parcial de datos. Si un fichero de registro se
228 corrompe parcialmente debido a un error de hardware o del sistema, a
229 menudo es posible reconstruir algunas o la mayoría de las revisiones a
230 partir de las secciones no corrompidas del fichero de registro, tanto
231 antes como después de la sección corrompida. Esto no sería posible con
232 un sistema de almacenamiento basado únicamente en deltas.
234 \section{Revision history, branching,
235 and merging}
237 Every entry in a Mercurial revlog knows the identity of its immediate
238 ancestor revision, usually referred to as its \emph{parent}. In fact,
239 a revision contains room for not one parent, but two. Mercurial uses
240 a special hash, called the ``null ID'', to represent the idea ``there
241 is no parent here''. This hash is simply a string of zeroes.
243 In figure~\ref{fig:concepts:revlog}, you can see an example of the
244 conceptual structure of a revlog. Filelogs, manifests, and changelogs
245 all have this same structure; they differ only in the kind of data
246 stored in each delta or snapshot.
248 The first revision in a revlog (at the bottom of the image) has the
249 null ID in both of its parent slots. For a ``normal'' revision, its
250 first parent slot contains the ID of its parent revision, and its
251 second contains the null ID, indicating that the revision has only one
252 real parent. Any two revisions that have the same parent ID are
253 branches. A revision that represents a merge between branches has two
254 normal revision IDs in its parent slots.
256 \begin{figure}[ht]
257 \centering
258 \grafix{revlog}
259 \caption{}
260 \label{fig:concepts:revlog}
261 \end{figure}
263 \section{The working directory}
265 In the working directory, Mercurial stores a snapshot of the files
266 from the repository as of a particular changeset.
268 The working directory ``knows'' which changeset it contains. When you
269 update the working directory to contain a particular changeset,
270 Mercurial looks up the appropriate revision of the manifest to find
271 out which files it was tracking at the time that changeset was
272 committed, and which revision of each file was then current. It then
273 recreates a copy of each of those files, with the same contents it had
274 when the changeset was committed.
276 The \emph{dirstate} contains Mercurial's knowledge of the working
277 directory. This details which changeset the working directory is
278 updated to, and all of the files that Mercurial is tracking in the
279 working directory.
281 Just as a revision of a revlog has room for two parents, so that it
282 can represent either a normal revision (with one parent) or a merge of
283 two earlier revisions, the dirstate has slots for two parents. When
284 you use the \hgcmd{update} command, the changeset that you update to
285 is stored in the ``first parent'' slot, and the null ID in the second.
286 When you \hgcmd{merge} with another changeset, the first parent
287 remains unchanged, and the second parent is filled in with the
288 changeset you're merging with. The \hgcmd{parents} command tells you
289 what the parents of the dirstate are.
291 \subsection{What happens when you commit}
293 The dirstate stores parent information for more than just book-keeping
294 purposes. Mercurial uses the parents of the dirstate as \emph{the
295 parents of a new changeset} when you perform a commit.
297 \begin{figure}[ht]
298 \centering
299 \grafix{wdir}
300 \caption{The working directory can have two parents}
301 \label{fig:concepts:wdir}
302 \end{figure}
304 Figure~\ref{fig:concepts:wdir} shows the normal state of the working
305 directory, where it has a single changeset as parent. That changeset
306 is the \emph{tip}, the newest changeset in the repository that has no
307 children.
309 \begin{figure}[ht]
310 \centering
311 \grafix{wdir-after-commit}
312 \caption{The working directory gains new parents after a commit}
313 \label{fig:concepts:wdir-after-commit}
314 \end{figure}
316 It's useful to think of the working directory as ``the changeset I'm
317 about to commit''. Any files that you tell Mercurial that you've
318 added, removed, renamed, or copied will be reflected in that
319 changeset, as will modifications to any files that Mercurial is
320 already tracking; the new changeset will have the parents of the
321 working directory as its parents.
323 After a commit, Mercurial will update the parents of the working
324 directory, so that the first parent is the ID of the new changeset,
325 and the second is the null ID. This is shown in
326 figure~\ref{fig:concepts:wdir-after-commit}. Mercurial doesn't touch
327 any of the files in the working directory when you commit; it just
328 modifies the dirstate to note its new parents.
330 \subsection{Creating a new head}
332 It's perfectly normal to update the working directory to a changeset
333 other than the current tip. For example, you might want to know what
334 your project looked like last Tuesday, or you could be looking through
335 changesets to see which one introduced a bug. In cases like this, the
336 natural thing to do is update the working directory to the changeset
337 you're interested in, and then examine the files in the working
338 directory directly to see their contents as they werea when you
339 committed that changeset. The effect of this is shown in
340 figure~\ref{fig:concepts:wdir-pre-branch}.
342 \begin{figure}[ht]
343 \centering
344 \grafix{wdir-pre-branch}
345 \caption{The working directory, updated to an older changeset}
346 \label{fig:concepts:wdir-pre-branch}
347 \end{figure}
349 Having updated the working directory to an older changeset, what
350 happens if you make some changes, and then commit? Mercurial behaves
351 in the same way as I outlined above. The parents of the working
352 directory become the parents of the new changeset. This new changeset
353 has no children, so it becomes the new tip. And the repository now
354 contains two changesets that have no children; we call these
355 \emph{heads}. You can see the structure that this creates in
356 figure~\ref{fig:concepts:wdir-branch}.
358 \begin{figure}[ht]
359 \centering
360 \grafix{wdir-branch}
361 \caption{After a commit made while synced to an older changeset}
362 \label{fig:concepts:wdir-branch}
363 \end{figure}
365 \begin{note}
366 If you're new to Mercurial, you should keep in mind a common
367 ``error'', which is to use the \hgcmd{pull} command without any
368 options. By default, the \hgcmd{pull} command \emph{does not}
369 update the working directory, so you'll bring new changesets into
370 your repository, but the working directory will stay synced at the
371 same changeset as before the pull. If you make some changes and
372 commit afterwards, you'll thus create a new head, because your
373 working directory isn't synced to whatever the current tip is.
375 I put the word ``error'' in quotes because all that you need to do
376 to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}. In
377 other words, this almost never has negative consequences; it just
378 surprises people. I'll discuss other ways to avoid this behaviour,
379 and why Mercurial behaves in this initially surprising way, later
380 on.
381 \end{note}
383 \subsection{Merging heads}
385 When you run the \hgcmd{merge} command, Mercurial leaves the first
386 parent of the working directory unchanged, and sets the second parent
387 to the changeset you're merging with, as shown in
388 figure~\ref{fig:concepts:wdir-merge}.
390 \begin{figure}[ht]
391 \centering
392 \grafix{wdir-merge}
393 \caption{Merging two heads}
394 \label{fig:concepts:wdir-merge}
395 \end{figure}
397 Mercurial also has to modify the working directory, to merge the files
398 managed in the two changesets. Simplified a little, the merging
399 process goes like this, for every file in the manifests of both
400 changesets.
401 \begin{itemize}
402 \item If neither changeset has modified a file, do nothing with that
403 file.
404 \item If one changeset has modified a file, and the other hasn't,
405 create the modified copy of the file in the working directory.
406 \item If one changeset has removed a file, and the other hasn't (or
407 has also deleted it), delete the file from the working directory.
408 \item If one changeset has removed a file, but the other has modified
409 the file, ask the user what to do: keep the modified file, or remove
410 it?
411 \item If both changesets have modified a file, invoke an external
412 merge program to choose the new contents for the merged file. This
413 may require input from the user.
414 \item If one changeset has modified a file, and the other has renamed
415 or copied the file, make sure that the changes follow the new name
416 of the file.
417 \end{itemize}
418 There are more details---merging has plenty of corner cases---but
419 these are the most common choices that are involved in a merge. As
420 you can see, most cases are completely automatic, and indeed most
421 merges finish automatically, without requiring your input to resolve
422 any conflicts.
424 When you're thinking about what happens when you commit after a merge,
425 once again the working directory is ``the changeset I'm about to
426 commit''. After the \hgcmd{merge} command completes, the working
427 directory has two parents; these will become the parents of the new
428 changeset.
430 Mercurial lets you perform multiple merges, but you must commit the
431 results of each individual merge as you go. This is necessary because
432 Mercurial only tracks two parents for both revisions and the working
433 directory. While it would be technically possible to merge multiple
434 changesets at once, the prospect of user confusion and making a
435 terrible mess of a merge immediately becomes overwhelming.
437 \section{Other interesting design features}
439 In the sections above, I've tried to highlight some of the most
440 important aspects of Mercurial's design, to illustrate that it pays
441 careful attention to reliability and performance. However, the
442 attention to detail doesn't stop there. There are a number of other
443 aspects of Mercurial's construction that I personally find
444 interesting. I'll detail a few of them here, separate from the ``big
445 ticket'' items above, so that if you're interested, you can gain a
446 better idea of the amount of thinking that goes into a well-designed
447 system.
449 \subsection{Clever compression}
451 When appropriate, Mercurial will store both snapshots and deltas in
452 compressed form. It does this by always \emph{trying to} compress a
453 snapshot or delta, but only storing the compressed version if it's
454 smaller than the uncompressed version.
456 This means that Mercurial does ``the right thing'' when storing a file
457 whose native form is compressed, such as a \texttt{zip} archive or a
458 JPEG image. When these types of files are compressed a second time,
459 the resulting file is usually bigger than the once-compressed form,
460 and so Mercurial will store the plain \texttt{zip} or JPEG.
462 Deltas between revisions of a compressed file are usually larger than
463 snapshots of the file, and Mercurial again does ``the right thing'' in
464 these cases. It finds that such a delta exceeds the threshold at
465 which it should store a complete snapshot of the file, so it stores
466 the snapshot, again saving space compared to a naive delta-only
467 approach.
469 \subsubsection{Network recompression}
471 When storing revisions on disk, Mercurial uses the ``deflate''
472 compression algorithm (the same one used by the popular \texttt{zip}
473 archive format), which balances good speed with a respectable
474 compression ratio. However, when transmitting revision data over a
475 network connection, Mercurial uncompresses the compressed revision
476 data.
478 If the connection is over HTTP, Mercurial recompresses the entire
479 stream of data using a compression algorithm that gives a better
480 compression ratio (the Burrows-Wheeler algorithm from the widely used
481 \texttt{bzip2} compression package). This combination of algorithm
482 and compression of the entire stream (instead of a revision at a time)
483 substantially reduces the number of bytes to be transferred, yielding
484 better network performance over almost all kinds of network.
486 (If the connection is over \command{ssh}, Mercurial \emph{doesn't}
487 recompress the stream, because \command{ssh} can already do this
488 itself.)
490 \subsection{Read/write ordering and atomicity}
492 Appending to files isn't the whole story when it comes to guaranteeing
493 that a reader won't see a partial write. If you recall
494 figure~\ref{fig:concepts:metadata}, revisions in the changelog point to
495 revisions in the manifest, and revisions in the manifest point to
496 revisions in filelogs. This hierarchy is deliberate.
498 A writer starts a transaction by writing filelog and manifest data,
499 and doesn't write any changelog data until those are finished. A
500 reader starts by reading changelog data, then manifest data, followed
501 by filelog data.
503 Since the writer has always finished writing filelog and manifest data
504 before it writes to the changelog, a reader will never read a pointer
505 to a partially written manifest revision from the changelog, and it will
506 never read a pointer to a partially written filelog revision from the
507 manifest.
509 \subsection{Concurrent access}
511 The read/write ordering and atomicity guarantees mean that Mercurial
512 never needs to \emph{lock} a repository when it's reading data, even
513 if the repository is being written to while the read is occurring.
514 This has a big effect on scalability; you can have an arbitrary number
515 of Mercurial processes safely reading data from a repository safely
516 all at once, no matter whether it's being written to or not.
518 The lockless nature of reading means that if you're sharing a
519 repository on a multi-user system, you don't need to grant other local
520 users permission to \emph{write} to your repository in order for them
521 to be able to clone it or pull changes from it; they only need
522 \emph{read} permission. (This is \emph{not} a common feature among
523 revision control systems, so don't take it for granted! Most require
524 readers to be able to lock a repository to access it safely, and this
525 requires write permission on at least one directory, which of course
526 makes for all kinds of nasty and annoying security and administrative
527 problems.)
529 Mercurial uses locks to ensure that only one process can write to a
530 repository at a time (the locking mechanism is safe even over
531 filesystems that are notoriously hostile to locking, such as NFS). If
532 a repository is locked, a writer will wait for a while to retry if the
533 repository becomes unlocked, but if the repository remains locked for
534 too long, the process attempting to write will time out after a while.
535 This means that your daily automated scripts won't get stuck forever
536 and pile up if a system crashes unnoticed, for example. (Yes, the
537 timeout is configurable, from zero to infinity.)
539 \subsubsection{Safe dirstate access}
541 As with revision data, Mercurial doesn't take a lock to read the
542 dirstate file; it does acquire a lock to write it. To avoid the
543 possibility of reading a partially written copy of the dirstate file,
544 Mercurial writes to a file with a unique name in the same directory as
545 the dirstate file, then renames the temporary file atomically to
546 \filename{dirstate}. The file named \filename{dirstate} is thus
547 guaranteed to be complete, not partially written.
549 \subsection{Avoiding seeks}
551 Critical to Mercurial's performance is the avoidance of seeks of the
552 disk head, since any seek is far more expensive than even a
553 comparatively large read operation.
555 This is why, for example, the dirstate is stored in a single file. If
556 there were a dirstate file per directory that Mercurial tracked, the
557 disk would seek once per directory. Instead, Mercurial reads the
558 entire single dirstate file in one step.
560 Mercurial also uses a ``copy on write'' scheme when cloning a
561 repository on local storage. Instead of copying every revlog file
562 from the old repository into the new repository, it makes a ``hard
563 link'', which is a shorthand way to say ``these two names point to the
564 same file''. When Mercurial is about to write to one of a revlog's
565 files, it checks to see if the number of names pointing at the file is
566 greater than one. If it is, more than one repository is using the
567 file, so Mercurial makes a new copy of the file that is private to
568 this repository.
570 A few revision control developers have pointed out that this idea of
571 making a complete private copy of a file is not very efficient in its
572 use of storage. While this is true, storage is cheap, and this method
573 gives the highest performance while deferring most book-keeping to the
574 operating system. An alternative scheme would most likely reduce
575 performance and increase the complexity of the software, each of which
576 is much more important to the ``feel'' of day-to-day use.
578 \subsection{Other contents of the dirstate}
580 Because Mercurial doesn't force you to tell it when you're modifying a
581 file, it uses the dirstate to store some extra information so it can
582 determine efficiently whether you have modified a file. For each file
583 in the working directory, it stores the time that it last modified the
584 file itself, and the size of the file at that time.
586 When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or
587 \hgcmd{copy} files, Mercurial updates the dirstate so that it knows
588 what to do with those files when you commit.
590 When Mercurial is checking the states of files in the working
591 directory, it first checks a file's modification time. If that has
592 not changed, the file must not have been modified. If the file's size
593 has changed, the file must have been modified. If the modification
594 time has changed, but the size has not, only then does Mercurial need
595 to read the actual contents of the file to see if they've changed.
596 Storing these few extra pieces of information dramatically reduces the
597 amount of data that Mercurial needs to read, which yields large
598 performance improvements compared to other revision control systems.
600 %%% Local Variables:
601 %%% mode: latex
602 %%% TeX-master: "00book"
603 %%% End: