# HG changeset patch # User Bryan O'Sullivan # Date 1163452889 28800 # Node ID 2fcead053b7abab7b66ea911ba0aefd0fbeb836e # Parent 34b8b7a15ea181c5179a34919d3b2fa4bb91f873 More. Concept. Fun. diff -r 34b8b7a15ea1 -r 2fcead053b7a en/Makefile --- a/en/Makefile Fri Nov 10 15:32:33 2006 -0800 +++ b/en/Makefile Mon Nov 13 13:21:29 2006 -0800 @@ -25,6 +25,7 @@ kdiff3.png \ metadata.svg \ mq-stack.svg \ + revlog.svg \ snapshot.svg \ tour-history.svg \ tour-merge-conflict.svg \ diff -r 34b8b7a15ea1 -r 2fcead053b7a en/concepts.tex --- a/en/concepts.tex Fri Nov 10 15:32:33 2006 -0800 +++ b/en/concepts.tex Mon Nov 13 13:21:29 2006 -0800 @@ -12,6 +12,10 @@ the software is doing when I perform a revision control task, I'm less likely to be surprised by its behaviour. +In this chapter, we'll initially cover the core concepts behind +Mercurial's design, then continue to discuss some of the interesting +details of its implementation. + \section{Mercurial's historical record} \subsection{Tracking the history of a single file} @@ -174,19 +178,23 @@ the next key frame is received. Also, the accumulation of encoding errors restarts anew with each key frame. -\subsection{Strong integrity} +\subsection{Identification and strong integrity} Along with delta or snapshot information, a revlog entry contains a cryptographic hash of the data that it represents. This makes it difficult to forge the contents of a revision, and easy to detect -accidental corruption. The hash that Mercurial uses is SHA-1, which -is 160 bits long. Although all revision data is hashed, the changeset +accidental corruption. + +Hashes provide more than a mere check against corruption; they are +used as the identifiers for revisions. The changeset identification hashes that you see as an end user are from revisions of the -changelog. Manifest and file hashes are only used behind the scenes. - -Mercurial checks these hashes when retrieving file revisions and when -pulling changes from a repository. If it encounters an integrity -problem, it will complain and stop whatever it's doing. +changelog. Although filelogs and the manifest also use hashes, +Mercurial only uses these behind the scenes. + +Mercurial verifies that hashes are correct when it retrieves file +revisions and when it pulls changes from another repository. If it +encounters an integrity problem, it will complain and stop whatever +it's doing. In addition to the effect it has on retrieval efficiency, Mercurial's use of periodic snapshots makes it more robust against partial data @@ -220,6 +228,35 @@ amount of data that Mercurial needs to read, which yields large performance improvements compared to other revision control systems. +\section{Revision history, branching, + and merging} + +Every entry in a Mercurial revlog knows the identity of its immediate +ancestor revision, usually referred to as its \emph{parent}. In fact, +a revision contains room for not one parent, but two. Mercurial uses +a special hash, called the ``null ID'', to represent the idea ``there +is no parent here''. This hash is simply a string of zeroes. + +In figure~\ref{fig:concepts:revlog}, you can see an example of the +conceptual structure of a revlog. Filelogs, manifests, and changelogs +all have this same structure; they differ only in the kind of data +stored in each delta or snapshot. + +The first revision in a revlog (at the bottom of the image) has the +null ID in both of its parent slots. For a ``normal'' revision, its +first parent slot contains the ID of its parent revision, and its +second contains the null ID, indicating that the revision has only one +real parent. Any two revisions that have the same parent ID are +branches. A revision that represents a merge between branches has two +normal revision IDs in its parent slots. + +\begin{figure}[ht] + \centering + \grafix{revlog} + \caption{} + \label{fig:concepts:revlog} +\end{figure} + \section{Other interesting design features} In the sections above, I've tried to highlight some of the most diff -r 34b8b7a15ea1 -r 2fcead053b7a en/revlog.svg --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/en/revlog.svg Mon Nov 13 13:21:29 2006 -0800 @@ -0,0 +1,1155 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Second parent + 32bf9a5f22c0 + + + + Revision hash + 34b8b7a15ea1 + + + + ... + Revision data (delta or snapshot) + + + + + + + First parent + 000000000000 + + + + Second parent + 000000000000 + + + + + Revision hash + ff9dc8bc2a8b + + + + ... + Revision data (delta or snapshot) + + + + + + + First parent + 34b8b7a15ea1 + + + + Second parent + 000000000000 + + + + Revision hash + 1b67dc96f27a + + + + ... + Revision data (delta or snapshot) + + + + + + + + First parent + ff9dc8bc2a8b + + + + Second parent + 000000000000 + + + + Revision hash + 5b80c922ebdd + + + + ... + Revision data (delta or snapshot) + + + + + + + First parent + ecacb6b4c9fd + + + + Second parent + 000000000000 + + + + Revision hash + 32bf9a5f22c0 + + + + ... + Revision data (delta or snapshot) + + + + + + First parent + ff9dc8bc2a8b + + + + Second parent + 000000000000 + + + + Revision hash + ecacb6b4c9fd + + + + ... + Revision data (delta or snapshot) + + + + + + + Head revision(no children) + Merge revision(two parents) + Branches(two revisions,same parent) + + + First revision(both parents null) + + First parent + 5b80c922ebdd + + + + +