Mercurial_ The Definitive Guide - Bryan O'Sullivan [6]
Revision control is a diverse field, so much so that it is referred to by many names and acronyms. Here are a few of the more common variations you’ll encounter:
Revision control system (RCS)
Software configuration management (SCM), or configuration management
Source code management
Source code control, or source control
Version control system (VCS)
Some people claim that these terms actually have different meanings, but in practice they overlap so much that there’s no agreed-upon or even useful way to tease them apart.
This Book Is a Work in Progress
I am releasing this book while I am still writing it, in the hope that it will prove useful to others. I am writing under an open license in the hope that you, my readers, will contribute feedback and perhaps content of your own.
About the Examples in This Book
This book takes an unusual approach to code samples. Every example is “live”—each one is actually the result of a shell script that executes the Mercurial commands you see. Every time an image of the book is built from its sources, all the example scripts are automatically run, and their current results compared against their expected results.
The advantage of this approach is that the examples are always accurate; they describe exactly the behavior of the version of Mercurial that’s mentioned at the front of the book. If I update the version of Mercurial that I’m documenting, and the output of some command changes, the build fails.
There is a small disadvantage to this approach, which is that the dates and times you’ll see in examples tend to be “squashed” together in a way that they wouldn’t be if the same commands were being typed by a human. Where a human can issue no more than one command every few seconds, with any resulting timestamps correspondingly spread out, my automated example scripts run many commands in one second.
As an instance of this, several consecutive commits in an example can show up as having occurred during the same second. You can see this occur in the bisect example in Finding the Source of a Bug, for instance.
So when you’re reading examples, don’t place too much weight on the dates or times you see in the output of commands. But do be confident that the behavior you’re seeing is consistent and reproducible.
Trends in the Field
There has been an unmistakable trend in the development and use of revision control tools over the past four decades, as people have become familiar with the capabilities of their tools and constrained by their limitations.
The first generation began by managing single files on individual computers. Although these tools represented a huge advance over ad-hoc manual revision control, their locking model and reliance on a single computer limited them to small, tightly knit teams.
The second generation loosened these constraints by moving to network-centered architectures and managing entire projects at a time. As projects grew larger, they ran into new problems. With clients needing to talk to servers very frequently, server scaling became an issue for large projects. An unreliable network connection could prevent remote users from being able to talk to the server at all. As open source projects started making read-only access available anonymously to anyone, people without commit privileges found that they could not use the tools to interact with a project in a natural way, as they could not record their changes.
The current generation of revision control tools is peer-to-peer in nature. All of these systems have dropped the dependency on a single central server, and allow people to distribute their revision control data to where it’s actually needed. Collaboration over the Internet has moved from being constrained by technology to a matter of choice and consensus. Modern tools can operate offline indefinitely and autonomously, with a network connection only needed when syncing changes with another repository.
A Few Advantages of Distributed Revision Control
Even though distributed revision control tools have