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