Mercurial: The Definitive Guide

Chapter 4. Behind the Scenes

Unlike many revision control systems, the concepts upon which Mercurial is built are simple enough that it’s easy to understand how the software really works. Knowing these details certainly isn’t necessary, so it is safe to skip this chapter. However, I think you will get more out of the software with a “mental model” of what’s going on.

Being able to understand what’s going on behind the scenes gives me confidence that Mercurial has been carefully designed to be both safe and efficient. And just as importantly, if it’s easy for me to retain a good idea of what the software is doing when I perform a revision control task, I’m less likely to be surprised by its behavior.

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.

Mercurial’s Historical Record

Tracking the History of a Single File

When Mercurial tracks modifications to a file, it stores the history of that file in a metadata object called a filelog. Each entry in the filelog contains enough information to reconstruct one revision of the file that is being tracked. Filelogs are stored as files in the .hg/store/data directory. A filelog contains two kinds of information: revision data, and an index to help Mercurial find a revision efficiently.

A file that is large, or has a lot of history, has its filelog stored in separate data (.d suffix) and index (.i suffix) files. For small files without ...