hgbook
view es/concepts.tex @ 393:2c2c86824c61
began translation of the "behind the scenes" chapter
| author | Javier Rojas <jerojasro@devnull.li> |
|---|---|
| date | Mon Nov 03 21:00:32 2008 -0500 (2008-11-03) |
| parents | 2fb78d342e07 |
| children | 149ea8ae39c4 |
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 of that file in a metadata object called a \emph{filelog}. Each entry
28 in the filelog contains enough information to reconstruct one revision
29 of the file that is being tracked. Filelogs are stored as files in
30 the \sdirname{.hg/store/data} directory. A filelog contains two kinds
31 of information: revision data, and an index to help Mercurial to find
32 a revision efficiently.
34 A file that is large, or has a lot of history, has its filelog stored
35 in separate data (``\texttt{.d}'' suffix) and index (``\texttt{.i}''
36 suffix) files. For small files without much history, the revision
37 data and index are combined in a single ``\texttt{.i}'' file. The
38 correspondence between a file in the working directory and the filelog
39 that tracks its history in the repository is illustrated in
40 figure~\ref{fig:concepts:filelog}.
42 \begin{figure}[ht]
43 \centering
44 \grafix{filelog}
45 \caption{Relationships between files in working directory and
46 filelogs in repository}
47 \label{fig:concepts:filelog}
48 \end{figure}
50 \subsection{Managing tracked files}
52 Mercurial uses a structure called a \emph{manifest} to collect
53 together information about the files that it tracks. Each entry in
54 the manifest contains information about the files present in a single
55 changeset. An entry records which files are present in the changeset,
56 the revision of each file, and a few other pieces of file metadata.
58 \subsection{Recording changeset information}
60 The \emph{changelog} contains information about each changeset. Each
61 revision records who committed a change, the changeset comment, other
62 pieces of changeset-related information, and the revision of the
63 manifest to use.
65 \subsection{Relationships between revisions}
67 Within a changelog, a manifest, or a filelog, each revision stores a
68 pointer to its immediate parent (or to its two parents, if it's a
69 merge revision). As I mentioned above, there are also relationships
70 between revisions \emph{across} these structures, and they are
71 hierarchical in nature.
73 For every changeset in a repository, there is exactly one revision
74 stored in the changelog. Each revision of the changelog contains a
75 pointer to a single revision of the manifest. A revision of the
76 manifest stores a pointer to a single revision of each filelog tracked
77 when that changeset was created. These relationships are illustrated
78 in figure~\ref{fig:concepts:metadata}.
80 \begin{figure}[ht]
81 \centering
82 \grafix{metadata}
83 \caption{Metadata relationships}
84 \label{fig:concepts:metadata}
85 \end{figure}
87 As the illustration shows, there is \emph{not} a ``one to one''
88 relationship between revisions in the changelog, manifest, or filelog.
89 If the manifest hasn't changed between two changesets, the changelog
90 entries for those changesets will point to the same revision of the
91 manifest. If a file that Mercurial tracks hasn't changed between two
92 changesets, the entry for that file in the two revisions of the
93 manifest will point to the same revision of its filelog.
95 \section{Safe, efficient storage}
97 The underpinnings of changelogs, manifests, and filelogs are provided
98 by a single structure called the \emph{revlog}.
100 \subsection{Efficient storage}
102 The revlog provides efficient storage of revisions using a
103 \emph{delta} mechanism. Instead of storing a complete copy of a file
104 for each revision, it stores the changes needed to transform an older
105 revision into the new revision. For many kinds of file data, these
106 deltas are typically a fraction of a percent of the size of a full
107 copy of a file.
109 Some obsolete revision control systems can only work with deltas of
110 text files. They must either store binary files as complete snapshots
111 or encoded into a text representation, both of which are wasteful
112 approaches. Mercurial can efficiently handle deltas of files with
113 arbitrary binary contents; it doesn't need to treat text as special.
115 \subsection{Safe operation}
116 \label{sec:concepts:txn}
118 Mercurial only ever \emph{appends} data to the end of a revlog file.
119 It never modifies a section of a file after it has written it. This
120 is both more robust and efficient than schemes that need to modify or
121 rewrite data.
123 In addition, Mercurial treats every write as part of a
124 \emph{transaction} that can span a number of files. A transaction is
125 \emph{atomic}: either the entire transaction succeeds and its effects
126 are all visible to readers in one go, or the whole thing is undone.
127 This guarantee of atomicity means that if you're running two copies of
128 Mercurial, where one is reading data and one is writing it, the reader
129 will never see a partially written result that might confuse it.
131 The fact that Mercurial only appends to files makes it easier to
132 provide this transactional guarantee. The easier it is to do stuff
133 like this, the more confident you should be that it's done correctly.
135 \subsection{Fast retrieval}
137 Mercurial cleverly avoids a pitfall common to all earlier
138 revision control systems: the problem of \emph{inefficient retrieval}.
139 Most revision control systems store the contents of a revision as an
140 incremental series of modifications against a ``snapshot''. To
141 reconstruct a specific revision, you must first read the snapshot, and
142 then every one of the revisions between the snapshot and your target
143 revision. The more history that a file accumulates, the more
144 revisions you must read, hence the longer it takes to reconstruct a
145 particular revision.
147 \begin{figure}[ht]
148 \centering
149 \grafix{snapshot}
150 \caption{Snapshot of a revlog, with incremental deltas}
151 \label{fig:concepts:snapshot}
152 \end{figure}
154 The innovation that Mercurial applies to this problem is simple but
155 effective. Once the cumulative amount of delta information stored
156 since the last snapshot exceeds a fixed threshold, it stores a new
157 snapshot (compressed, of course), instead of another delta. This
158 makes it possible to reconstruct \emph{any} revision of a file
159 quickly. This approach works so well that it has since been copied by
160 several other revision control systems.
162 Figure~\ref{fig:concepts:snapshot} illustrates the idea. In an entry
163 in a revlog's index file, Mercurial stores the range of entries from
164 the data file that it must read to reconstruct a particular revision.
166 \subsubsection{Aside: the influence of video compression}
168 If you're familiar with video compression or have ever watched a TV
169 feed through a digital cable or satellite service, you may know that
170 most video compression schemes store each frame of video as a delta
171 against its predecessor frame. In addition, these schemes use
172 ``lossy'' compression techniques to increase the compression ratio, so
173 visual errors accumulate over the course of a number of inter-frame
174 deltas.
176 Because it's possible for a video stream to ``drop out'' occasionally
177 due to signal glitches, and to limit the accumulation of artefacts
178 introduced by the lossy compression process, video encoders
179 periodically insert a complete frame (called a ``key frame'') into the
180 video stream; the next delta is generated against that frame. This
181 means that if the video signal gets interrupted, it will resume once
182 the next key frame is received. Also, the accumulation of encoding
183 errors restarts anew with each key frame.
185 \subsection{Identification and strong integrity}
187 Along with delta or snapshot information, a revlog entry contains a
188 cryptographic hash of the data that it represents. This makes it
189 difficult to forge the contents of a revision, and easy to detect
190 accidental corruption.
192 Hashes provide more than a mere check against corruption; they are
193 used as the identifiers for revisions. The changeset identification
194 hashes that you see as an end user are from revisions of the
195 changelog. Although filelogs and the manifest also use hashes,
196 Mercurial only uses these behind the scenes.
198 Mercurial verifies that hashes are correct when it retrieves file
199 revisions and when it pulls changes from another repository. If it
200 encounters an integrity problem, it will complain and stop whatever
201 it's doing.
203 In addition to the effect it has on retrieval efficiency, Mercurial's
204 use of periodic snapshots makes it more robust against partial data
205 corruption. If a revlog becomes partly corrupted due to a hardware
206 error or system bug, it's often possible to reconstruct some or most
207 revisions from the uncorrupted sections of the revlog, both before and
208 after the corrupted section. This would not be possible with a
209 delta-only storage model.
211 \section{Revision history, branching,
212 and merging}
214 Every entry in a Mercurial revlog knows the identity of its immediate
215 ancestor revision, usually referred to as its \emph{parent}. In fact,
216 a revision contains room for not one parent, but two. Mercurial uses
217 a special hash, called the ``null ID'', to represent the idea ``there
218 is no parent here''. This hash is simply a string of zeroes.
220 In figure~\ref{fig:concepts:revlog}, you can see an example of the
221 conceptual structure of a revlog. Filelogs, manifests, and changelogs
222 all have this same structure; they differ only in the kind of data
223 stored in each delta or snapshot.
225 The first revision in a revlog (at the bottom of the image) has the
226 null ID in both of its parent slots. For a ``normal'' revision, its
227 first parent slot contains the ID of its parent revision, and its
228 second contains the null ID, indicating that the revision has only one
229 real parent. Any two revisions that have the same parent ID are
230 branches. A revision that represents a merge between branches has two
231 normal revision IDs in its parent slots.
233 \begin{figure}[ht]
234 \centering
235 \grafix{revlog}
236 \caption{}
237 \label{fig:concepts:revlog}
238 \end{figure}
240 \section{The working directory}
242 In the working directory, Mercurial stores a snapshot of the files
243 from the repository as of a particular changeset.
245 The working directory ``knows'' which changeset it contains. When you
246 update the working directory to contain a particular changeset,
247 Mercurial looks up the appropriate revision of the manifest to find
248 out which files it was tracking at the time that changeset was
249 committed, and which revision of each file was then current. It then
250 recreates a copy of each of those files, with the same contents it had
251 when the changeset was committed.
253 The \emph{dirstate} contains Mercurial's knowledge of the working
254 directory. This details which changeset the working directory is
255 updated to, and all of the files that Mercurial is tracking in the
256 working directory.
258 Just as a revision of a revlog has room for two parents, so that it
259 can represent either a normal revision (with one parent) or a merge of
260 two earlier revisions, the dirstate has slots for two parents. When
261 you use the \hgcmd{update} command, the changeset that you update to
262 is stored in the ``first parent'' slot, and the null ID in the second.
263 When you \hgcmd{merge} with another changeset, the first parent
264 remains unchanged, and the second parent is filled in with the
265 changeset you're merging with. The \hgcmd{parents} command tells you
266 what the parents of the dirstate are.
268 \subsection{What happens when you commit}
270 The dirstate stores parent information for more than just book-keeping
271 purposes. Mercurial uses the parents of the dirstate as \emph{the
272 parents of a new changeset} when you perform a commit.
274 \begin{figure}[ht]
275 \centering
276 \grafix{wdir}
277 \caption{The working directory can have two parents}
278 \label{fig:concepts:wdir}
279 \end{figure}
281 Figure~\ref{fig:concepts:wdir} shows the normal state of the working
282 directory, where it has a single changeset as parent. That changeset
283 is the \emph{tip}, the newest changeset in the repository that has no
284 children.
286 \begin{figure}[ht]
287 \centering
288 \grafix{wdir-after-commit}
289 \caption{The working directory gains new parents after a commit}
290 \label{fig:concepts:wdir-after-commit}
291 \end{figure}
293 It's useful to think of the working directory as ``the changeset I'm
294 about to commit''. Any files that you tell Mercurial that you've
295 added, removed, renamed, or copied will be reflected in that
296 changeset, as will modifications to any files that Mercurial is
297 already tracking; the new changeset will have the parents of the
298 working directory as its parents.
300 After a commit, Mercurial will update the parents of the working
301 directory, so that the first parent is the ID of the new changeset,
302 and the second is the null ID. This is shown in
303 figure~\ref{fig:concepts:wdir-after-commit}. Mercurial doesn't touch
304 any of the files in the working directory when you commit; it just
305 modifies the dirstate to note its new parents.
307 \subsection{Creating a new head}
309 It's perfectly normal to update the working directory to a changeset
310 other than the current tip. For example, you might want to know what
311 your project looked like last Tuesday, or you could be looking through
312 changesets to see which one introduced a bug. In cases like this, the
313 natural thing to do is update the working directory to the changeset
314 you're interested in, and then examine the files in the working
315 directory directly to see their contents as they werea when you
316 committed that changeset. The effect of this is shown in
317 figure~\ref{fig:concepts:wdir-pre-branch}.
319 \begin{figure}[ht]
320 \centering
321 \grafix{wdir-pre-branch}
322 \caption{The working directory, updated to an older changeset}
323 \label{fig:concepts:wdir-pre-branch}
324 \end{figure}
326 Having updated the working directory to an older changeset, what
327 happens if you make some changes, and then commit? Mercurial behaves
328 in the same way as I outlined above. The parents of the working
329 directory become the parents of the new changeset. This new changeset
330 has no children, so it becomes the new tip. And the repository now
331 contains two changesets that have no children; we call these
332 \emph{heads}. You can see the structure that this creates in
333 figure~\ref{fig:concepts:wdir-branch}.
335 \begin{figure}[ht]
336 \centering
337 \grafix{wdir-branch}
338 \caption{After a commit made while synced to an older changeset}
339 \label{fig:concepts:wdir-branch}
340 \end{figure}
342 \begin{note}
343 If you're new to Mercurial, you should keep in mind a common
344 ``error'', which is to use the \hgcmd{pull} command without any
345 options. By default, the \hgcmd{pull} command \emph{does not}
346 update the working directory, so you'll bring new changesets into
347 your repository, but the working directory will stay synced at the
348 same changeset as before the pull. If you make some changes and
349 commit afterwards, you'll thus create a new head, because your
350 working directory isn't synced to whatever the current tip is.
352 I put the word ``error'' in quotes because all that you need to do
353 to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}. In
354 other words, this almost never has negative consequences; it just
355 surprises people. I'll discuss other ways to avoid this behaviour,
356 and why Mercurial behaves in this initially surprising way, later
357 on.
358 \end{note}
360 \subsection{Merging heads}
362 When you run the \hgcmd{merge} command, Mercurial leaves the first
363 parent of the working directory unchanged, and sets the second parent
364 to the changeset you're merging with, as shown in
365 figure~\ref{fig:concepts:wdir-merge}.
367 \begin{figure}[ht]
368 \centering
369 \grafix{wdir-merge}
370 \caption{Merging two heads}
371 \label{fig:concepts:wdir-merge}
372 \end{figure}
374 Mercurial also has to modify the working directory, to merge the files
375 managed in the two changesets. Simplified a little, the merging
376 process goes like this, for every file in the manifests of both
377 changesets.
378 \begin{itemize}
379 \item If neither changeset has modified a file, do nothing with that
380 file.
381 \item If one changeset has modified a file, and the other hasn't,
382 create the modified copy of the file in the working directory.
383 \item If one changeset has removed a file, and the other hasn't (or
384 has also deleted it), delete the file from the working directory.
385 \item If one changeset has removed a file, but the other has modified
386 the file, ask the user what to do: keep the modified file, or remove
387 it?
388 \item If both changesets have modified a file, invoke an external
389 merge program to choose the new contents for the merged file. This
390 may require input from the user.
391 \item If one changeset has modified a file, and the other has renamed
392 or copied the file, make sure that the changes follow the new name
393 of the file.
394 \end{itemize}
395 There are more details---merging has plenty of corner cases---but
396 these are the most common choices that are involved in a merge. As
397 you can see, most cases are completely automatic, and indeed most
398 merges finish automatically, without requiring your input to resolve
399 any conflicts.
401 When you're thinking about what happens when you commit after a merge,
402 once again the working directory is ``the changeset I'm about to
403 commit''. After the \hgcmd{merge} command completes, the working
404 directory has two parents; these will become the parents of the new
405 changeset.
407 Mercurial lets you perform multiple merges, but you must commit the
408 results of each individual merge as you go. This is necessary because
409 Mercurial only tracks two parents for both revisions and the working
410 directory. While it would be technically possible to merge multiple
411 changesets at once, the prospect of user confusion and making a
412 terrible mess of a merge immediately becomes overwhelming.
414 \section{Other interesting design features}
416 In the sections above, I've tried to highlight some of the most
417 important aspects of Mercurial's design, to illustrate that it pays
418 careful attention to reliability and performance. However, the
419 attention to detail doesn't stop there. There are a number of other
420 aspects of Mercurial's construction that I personally find
421 interesting. I'll detail a few of them here, separate from the ``big
422 ticket'' items above, so that if you're interested, you can gain a
423 better idea of the amount of thinking that goes into a well-designed
424 system.
426 \subsection{Clever compression}
428 When appropriate, Mercurial will store both snapshots and deltas in
429 compressed form. It does this by always \emph{trying to} compress a
430 snapshot or delta, but only storing the compressed version if it's
431 smaller than the uncompressed version.
433 This means that Mercurial does ``the right thing'' when storing a file
434 whose native form is compressed, such as a \texttt{zip} archive or a
435 JPEG image. When these types of files are compressed a second time,
436 the resulting file is usually bigger than the once-compressed form,
437 and so Mercurial will store the plain \texttt{zip} or JPEG.
439 Deltas between revisions of a compressed file are usually larger than
440 snapshots of the file, and Mercurial again does ``the right thing'' in
441 these cases. It finds that such a delta exceeds the threshold at
442 which it should store a complete snapshot of the file, so it stores
443 the snapshot, again saving space compared to a naive delta-only
444 approach.
446 \subsubsection{Network recompression}
448 When storing revisions on disk, Mercurial uses the ``deflate''
449 compression algorithm (the same one used by the popular \texttt{zip}
450 archive format), which balances good speed with a respectable
451 compression ratio. However, when transmitting revision data over a
452 network connection, Mercurial uncompresses the compressed revision
453 data.
455 If the connection is over HTTP, Mercurial recompresses the entire
456 stream of data using a compression algorithm that gives a better
457 compression ratio (the Burrows-Wheeler algorithm from the widely used
458 \texttt{bzip2} compression package). This combination of algorithm
459 and compression of the entire stream (instead of a revision at a time)
460 substantially reduces the number of bytes to be transferred, yielding
461 better network performance over almost all kinds of network.
463 (If the connection is over \command{ssh}, Mercurial \emph{doesn't}
464 recompress the stream, because \command{ssh} can already do this
465 itself.)
467 \subsection{Read/write ordering and atomicity}
469 Appending to files isn't the whole story when it comes to guaranteeing
470 that a reader won't see a partial write. If you recall
471 figure~\ref{fig:concepts:metadata}, revisions in the changelog point to
472 revisions in the manifest, and revisions in the manifest point to
473 revisions in filelogs. This hierarchy is deliberate.
475 A writer starts a transaction by writing filelog and manifest data,
476 and doesn't write any changelog data until those are finished. A
477 reader starts by reading changelog data, then manifest data, followed
478 by filelog data.
480 Since the writer has always finished writing filelog and manifest data
481 before it writes to the changelog, a reader will never read a pointer
482 to a partially written manifest revision from the changelog, and it will
483 never read a pointer to a partially written filelog revision from the
484 manifest.
486 \subsection{Concurrent access}
488 The read/write ordering and atomicity guarantees mean that Mercurial
489 never needs to \emph{lock} a repository when it's reading data, even
490 if the repository is being written to while the read is occurring.
491 This has a big effect on scalability; you can have an arbitrary number
492 of Mercurial processes safely reading data from a repository safely
493 all at once, no matter whether it's being written to or not.
495 The lockless nature of reading means that if you're sharing a
496 repository on a multi-user system, you don't need to grant other local
497 users permission to \emph{write} to your repository in order for them
498 to be able to clone it or pull changes from it; they only need
499 \emph{read} permission. (This is \emph{not} a common feature among
500 revision control systems, so don't take it for granted! Most require
501 readers to be able to lock a repository to access it safely, and this
502 requires write permission on at least one directory, which of course
503 makes for all kinds of nasty and annoying security and administrative
504 problems.)
506 Mercurial uses locks to ensure that only one process can write to a
507 repository at a time (the locking mechanism is safe even over
508 filesystems that are notoriously hostile to locking, such as NFS). If
509 a repository is locked, a writer will wait for a while to retry if the
510 repository becomes unlocked, but if the repository remains locked for
511 too long, the process attempting to write will time out after a while.
512 This means that your daily automated scripts won't get stuck forever
513 and pile up if a system crashes unnoticed, for example. (Yes, the
514 timeout is configurable, from zero to infinity.)
516 \subsubsection{Safe dirstate access}
518 As with revision data, Mercurial doesn't take a lock to read the
519 dirstate file; it does acquire a lock to write it. To avoid the
520 possibility of reading a partially written copy of the dirstate file,
521 Mercurial writes to a file with a unique name in the same directory as
522 the dirstate file, then renames the temporary file atomically to
523 \filename{dirstate}. The file named \filename{dirstate} is thus
524 guaranteed to be complete, not partially written.
526 \subsection{Avoiding seeks}
528 Critical to Mercurial's performance is the avoidance of seeks of the
529 disk head, since any seek is far more expensive than even a
530 comparatively large read operation.
532 This is why, for example, the dirstate is stored in a single file. If
533 there were a dirstate file per directory that Mercurial tracked, the
534 disk would seek once per directory. Instead, Mercurial reads the
535 entire single dirstate file in one step.
537 Mercurial also uses a ``copy on write'' scheme when cloning a
538 repository on local storage. Instead of copying every revlog file
539 from the old repository into the new repository, it makes a ``hard
540 link'', which is a shorthand way to say ``these two names point to the
541 same file''. When Mercurial is about to write to one of a revlog's
542 files, it checks to see if the number of names pointing at the file is
543 greater than one. If it is, more than one repository is using the
544 file, so Mercurial makes a new copy of the file that is private to
545 this repository.
547 A few revision control developers have pointed out that this idea of
548 making a complete private copy of a file is not very efficient in its
549 use of storage. While this is true, storage is cheap, and this method
550 gives the highest performance while deferring most book-keeping to the
551 operating system. An alternative scheme would most likely reduce
552 performance and increase the complexity of the software, each of which
553 is much more important to the ``feel'' of day-to-day use.
555 \subsection{Other contents of the dirstate}
557 Because Mercurial doesn't force you to tell it when you're modifying a
558 file, it uses the dirstate to store some extra information so it can
559 determine efficiently whether you have modified a file. For each file
560 in the working directory, it stores the time that it last modified the
561 file itself, and the size of the file at that time.
563 When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or
564 \hgcmd{copy} files, Mercurial updates the dirstate so that it knows
565 what to do with those files when you commit.
567 When Mercurial is checking the states of files in the working
568 directory, it first checks a file's modification time. If that has
569 not changed, the file must not have been modified. If the file's size
570 has changed, the file must have been modified. If the modification
571 time has changed, but the size has not, only then does Mercurial need
572 to read the actual contents of the file to see if they've changed.
573 Storing these few extra pieces of information dramatically reduces the
574 amount of data that Mercurial needs to read, which yields large
575 performance improvements compared to other revision control systems.
577 %%% Local Variables:
578 %%% mode: latex
579 %%% TeX-master: "00book"
580 %%% End: