bos@553: bos@553: bos@558: bos@572: bos@553: Introduction bos@553: bos@553: bos@553: About revision control bos@553: bos@553: Revision control is the process of managing multiple bos@553: versions of a piece of information. In its simplest form, this bos@553: is something that many people do by hand: every time you modify bos@553: a file, save it under a new name that contains a number, each bos@553: one higher than the number of the preceding version. bos@553: bos@553: Manually managing multiple versions of even a single file is bos@553: an error-prone task, though, so software tools to help automate bos@553: this process have long been available. The earliest automated bos@553: revision control tools were intended to help a single user to bos@553: manage revisions of a single file. Over the past few decades, bos@553: the scope of revision control tools has expanded greatly; they bos@553: now manage multiple files, and help multiple people to work bos@553: together. The best modern revision control tools have no bos@553: problem coping with thousands of people working together on bos@553: projects that consist of hundreds of thousands of files. bos@553: bos@553: bos@553: Why use revision control? bos@553: bos@553: There are a number of reasons why you or your team might bos@553: want to use an automated revision control tool for a bos@553: project. bos@553: bos@553: It will track the history and evolution of bos@553: your project, so you don't have to. For every change, bos@553: you'll have a log of who made it; bos@553: why they made it; bos@553: when they made it; and bos@553: what the change bos@553: was. bos@553: When you're working with other people, bos@553: revision control software makes it easier for you to bos@553: collaborate. For example, when people more or less bos@553: simultaneously make potentially incompatible changes, the bos@553: software will help you to identify and resolve those bos@553: conflicts. bos@553: It can help you to recover from mistakes. If bos@553: you make a change that later turns out to be in error, you bos@553: can revert to an earlier version of one or more files. In bos@553: fact, a really good revision control bos@553: tool will even help you to efficiently figure out exactly bos@553: when a problem was introduced (see section for details). bos@553: It will help you to work simultaneously on, bos@553: and manage the drift between, multiple versions of your bos@553: project. bos@553: Most of these reasons are equally valid---at least in bos@553: theory---whether you're working on a project by yourself, or bos@553: with a hundred other people. bos@553: bos@553: A key question about the practicality of revision control bos@553: at these two different scales (lone hacker and bos@553: huge team) is how its bos@553: benefits compare to its bos@553: costs. A revision control tool that's bos@553: difficult to understand or use is going to impose a high bos@553: cost. bos@553: bos@553: A five-hundred-person project is likely to collapse under bos@553: its own weight almost immediately without a revision control bos@553: tool and process. In this case, the cost of using revision bos@553: control might hardly seem worth considering, since bos@553: without it, failure is almost bos@553: guaranteed. bos@553: bos@553: On the other hand, a one-person quick hack bos@553: might seem like a poor place to use a revision control tool, bos@553: because surely the cost of using one must be close to the bos@553: overall cost of the project. Right? bos@553: bos@553: Mercurial uniquely supports both of bos@553: these scales of development. You can learn the basics in just bos@553: a few minutes, and due to its low overhead, you can apply bos@553: revision control to the smallest of projects with ease. Its bos@553: simplicity means you won't have a lot of abstruse concepts or bos@553: command sequences competing for mental space with whatever bos@553: you're really trying to do. At the same bos@553: time, Mercurial's high performance and peer-to-peer nature let bos@553: you scale painlessly to handle large projects. bos@553: bos@553: No revision control tool can rescue a poorly run project, bos@553: but a good choice of tools can make a huge difference to the bos@553: fluidity with which you can work on a project. bos@553: bos@553: bos@553: bos@553: The many names of revision control bos@553: bos@553: Revision control is a diverse field, so much so that it bos@553: doesn't actually have a single name or acronym. Here are a bos@553: few of the more common names and acronyms you'll bos@553: encounter: bos@553: bos@553: Revision control (RCS) bos@553: Software configuration management (SCM), or bos@553: configuration management bos@553: Source code management bos@553: Source code control, or source bos@553: control bos@553: Version control bos@553: (VCS) bos@553: Some people claim that these terms actually have different bos@553: meanings, but in practice they overlap so much that there's no bos@553: agreed or even useful way to tease them apart. bos@553: bos@553: bos@553: bos@553: bos@553: A short history of revision control bos@553: bos@553: The best known of the old-time revision control tools is bos@553: SCCS (Source Code Control System), which Marc Rochkind wrote at bos@553: Bell Labs, in the early 1970s. SCCS operated on individual bos@553: files, and required every person working on a project to have bos@553: access to a shared workspace on a single system. Only one bos@553: person could modify a file at any time; arbitration for access bos@553: to files was via locks. It was common for people to lock files, bos@553: and later forget to unlock them, preventing anyone else from bos@553: modifying those files without the help of an bos@553: administrator. bos@553: bos@553: Walter Tichy developed a free alternative to SCCS in the ori@561: early 1980s; he called his program RCS (Revision Control System). bos@553: Like SCCS, RCS required developers to work in a single shared bos@553: workspace, and to lock files to prevent multiple people from bos@553: modifying them simultaneously. bos@553: bos@553: Later in the 1980s, Dick Grune used RCS as a building block bos@553: for a set of shell scripts he initially called cmt, but then bos@553: renamed to CVS (Concurrent Versions System). The big innovation bos@553: of CVS was that it let developers work simultaneously and bos@553: somewhat independently in their own personal workspaces. The bos@553: personal workspaces prevented developers from stepping on each bos@553: other's toes all the time, as was common with SCCS and RCS. Each bos@553: developer had a copy of every project file, and could modify bos@553: their copies independently. They had to merge their edits prior bos@553: to committing changes to the central repository. bos@553: bos@553: Brian Berliner took Grune's original scripts and rewrote bos@553: them in C, releasing in 1989 the code that has since developed bos@553: into the modern version of CVS. CVS subsequently acquired the bos@553: ability to operate over a network connection, giving it a bos@553: client/server architecture. CVS's architecture is centralised; bos@553: only the server has a copy of the history of the project. Client bos@553: workspaces just contain copies of recent versions of the bos@553: project's files, and a little metadata to tell them where the bos@553: server is. CVS has been enormously successful; it is probably bos@553: the world's most widely used revision control system. bos@553: bos@553: In the early 1990s, Sun Microsystems developed an early bos@553: distributed revision control system, called TeamWare. A bos@553: TeamWare workspace contains a complete copy of the project's bos@553: history. TeamWare has no notion of a central repository. (CVS bos@553: relied upon RCS for its history storage; TeamWare used bos@553: SCCS.) bos@553: bos@553: As the 1990s progressed, awareness grew of a number of bos@553: problems with CVS. It records simultaneous changes to multiple bos@553: files individually, instead of grouping them together as a bos@553: single logically atomic operation. It does not manage its file bos@553: hierarchy well; it is easy to make a mess of a repository by bos@553: renaming files and directories. Worse, its source code is bos@553: difficult to read and maintain, which made the pain bos@553: level of fixing these architectural problems bos@553: prohibitive. bos@553: bos@553: In 2001, Jim Blandy and Karl Fogel, two developers who had bos@553: worked on CVS, started a project to replace it with a tool that bos@553: would have a better architecture and cleaner code. The result, bos@553: Subversion, does not stray from CVS's centralised client/server bos@553: model, but it adds multi-file atomic commits, better namespace bos@553: management, and a number of other features that make it a bos@553: generally better tool than CVS. Since its initial release, it bos@553: has rapidly grown in popularity. bos@553: bos@553: More or less simultaneously, Graydon Hoare began working on bos@553: an ambitious distributed revision control system that he named bos@553: Monotone. While Monotone addresses many of CVS's design flaws bos@553: and has a peer-to-peer architecture, it goes beyond earlier (and bos@553: subsequent) revision control tools in a number of innovative bos@553: ways. It uses cryptographic hashes as identifiers, and has an bos@553: integral notion of trust for code from different bos@553: sources. bos@553: bos@553: Mercurial began life in 2005. While a few aspects of its bos@553: design are influenced by Monotone, Mercurial focuses on ease of bos@553: use, high performance, and scalability to very large bos@553: projects. bos@553: bos@553: bos@553: bos@553: Trends in revision control bos@553: bos@553: There has been an unmistakable trend in the development and bos@553: use of revision control tools over the past four decades, as bos@553: people have become familiar with the capabilities of their tools bos@553: and constrained by their limitations. bos@553: bos@553: The first generation began by managing single files on bos@553: individual computers. Although these tools represented a huge bos@553: advance over ad-hoc manual revision control, their locking model bos@553: and reliance on a single computer limited them to small, bos@553: tightly-knit teams. bos@553: bos@553: The second generation loosened these constraints by moving bos@553: to network-centered architectures, and managing entire projects bos@553: at a time. As projects grew larger, they ran into new problems. bos@553: With clients needing to talk to servers very frequently, server bos@553: scaling became an issue for large projects. An unreliable bos@553: network connection could prevent remote users from being able to bos@553: talk to the server at all. As open source projects started bos@553: making read-only access available anonymously to anyone, people bos@553: without commit privileges found that they could not use the bos@553: tools to interact with a project in a natural way, as they could bos@553: not record their changes. bos@553: bos@553: The current generation of revision control tools is bos@553: peer-to-peer in nature. All of these systems have dropped the bos@553: dependency on a single central server, and allow people to bos@553: distribute their revision control data to where it's actually bos@553: needed. Collaboration over the Internet has moved from bos@553: constrained by technology to a matter of choice and consensus. bos@553: Modern tools can operate offline indefinitely and autonomously, bos@553: with a network connection only needed when syncing changes with bos@553: another repository. bos@553: bos@553: bos@553: bos@553: A few of the advantages of distributed revision bos@553: control bos@553: bos@553: Even though distributed revision control tools have for bos@553: several years been as robust and usable as their bos@553: previous-generation counterparts, people using older tools have bos@553: not yet necessarily woken up to their advantages. There are a bos@553: number of ways in which distributed tools shine relative to bos@553: centralised ones. bos@553: bos@553: For an individual developer, distributed tools are almost bos@553: always much faster than centralised tools. This is for a simple bos@553: reason: a centralised tool needs to talk over the network for bos@553: many common operations, because most metadata is stored in a bos@553: single copy on the central server. A distributed tool stores bos@553: all of its metadata locally. All else being equal, talking over bos@553: the network adds overhead to a centralised tool. Don't bos@553: underestimate the value of a snappy, responsive tool: you're bos@553: going to spend a lot of time interacting with your revision bos@553: control software. bos@553: bos@553: Distributed tools are indifferent to the vagaries of your bos@553: server infrastructure, again because they replicate metadata to bos@553: so many locations. If you use a centralised system and your bos@553: server catches fire, you'd better hope that your backup media bos@553: are reliable, and that your last backup was recent and actually bos@553: worked. With a distributed tool, you have many backups bos@553: available on every contributor's computer. bos@553: bos@553: The reliability of your network will affect distributed bos@553: tools far less than it will centralised tools. You can't even bos@553: use a centralised tool without a network connection, except for bos@553: a few highly constrained commands. With a distributed tool, if bos@553: your network connection goes down while you're working, you may bos@553: not even notice. The only thing you won't be able to do is talk bos@553: to repositories on other computers, something that is relatively bos@553: rare compared with local operations. If you have a far-flung bos@553: team of collaborators, this may be significant. bos@553: bos@553: bos@553: Advantages for open source projects bos@553: bos@553: If you take a shine to an open source project and decide bos@553: that you would like to start hacking on it, and that project bos@553: uses a distributed revision control tool, you are at once a bos@553: peer with the people who consider themselves the bos@553: core of that project. If they publish their bos@553: repositories, you can immediately copy their project history, bos@553: start making changes, and record your work, using the same bos@553: tools in the same ways as insiders. By contrast, with a bos@553: centralised tool, you must use the software in a read bos@553: only mode unless someone grants you permission to bos@553: commit changes to their central server. Until then, you won't bos@553: be able to record changes, and your local modifications will bos@553: be at risk of corruption any time you try to update your bos@553: client's view of the repository. bos@553: bos@553: bos@553: The forking non-problem bos@553: bos@553: It has been suggested that distributed revision control bos@553: tools pose some sort of risk to open source projects because bos@553: they make it easy to fork the development of bos@553: a project. A fork happens when there are differences in bos@553: opinion or attitude between groups of developers that cause bos@553: them to decide that they can't work together any longer. bos@553: Each side takes a more or less complete copy of the bos@553: project's source code, and goes off in its own bos@553: direction. bos@553: bos@553: Sometimes the camps in a fork decide to reconcile their bos@553: differences. With a centralised revision control system, the bos@553: technical process of reconciliation is bos@553: painful, and has to be performed largely by hand. You have bos@553: to decide whose revision history is going to bos@553: win, and graft the other team's changes into bos@553: the tree somehow. This usually loses some or all of one bos@553: side's revision history. bos@553: bos@553: What distributed tools do with respect to forking is bos@553: they make forking the only way to bos@553: develop a project. Every single change that you make is bos@553: potentially a fork point. The great strength of this bos@553: approach is that a distributed revision control tool has to bos@553: be really good at merging forks, bos@553: because forks are absolutely fundamental: they happen all bos@553: the time. bos@553: bos@553: If every piece of work that everybody does, all the bos@553: time, is framed in terms of forking and merging, then what bos@553: the open source world refers to as a fork bos@553: becomes purely a social issue. If bos@553: anything, distributed tools lower the bos@553: likelihood of a fork: bos@553: bos@553: They eliminate the social distinction that bos@553: centralised tools impose: that between insiders (people bos@553: with commit access) and outsiders (people bos@553: without). bos@553: They make it easier to reconcile after a bos@553: social fork, because all that's involved from the bos@553: perspective of the revision control software is just bos@553: another merge. bos@553: bos@553: Some people resist distributed tools because they want bos@553: to retain tight control over their projects, and they bos@553: believe that centralised tools give them this control. bos@553: However, if you're of this belief, and you publish your CVS ori@561: or Subversion repositories publicly, there are plenty of bos@553: tools available that can pull out your entire project's bos@553: history (albeit slowly) and recreate it somewhere that you bos@553: don't control. So while your control in this case is bos@553: illusory, you are forgoing the ability to fluidly bos@553: collaborate with whatever people feel compelled to mirror bos@553: and fork your history. bos@553: bos@553: bos@553: bos@553: bos@553: Advantages for commercial projects bos@553: bos@553: Many commercial projects are undertaken by teams that are bos@553: scattered across the globe. Contributors who are far from a bos@553: central server will see slower command execution and perhaps bos@553: less reliability. Commercial revision control systems attempt bos@553: to ameliorate these problems with remote-site replication bos@553: add-ons that are typically expensive to buy and cantankerous bos@553: to administer. A distributed system doesn't suffer from these bos@553: problems in the first place. Better yet, you can easily set bos@553: up multiple authoritative servers, say one per site, so that bos@553: there's no redundant communication between repositories over bos@553: expensive long-haul network links. bos@553: bos@553: Centralised revision control systems tend to have bos@553: relatively low scalability. It's not unusual for an expensive bos@553: centralised system to fall over under the combined load of bos@553: just a few dozen concurrent users. Once again, the typical bos@553: response tends to be an expensive and clunky replication bos@553: facility. Since the load on a central server---if you have bos@553: one at all---is many times lower with a distributed tool bos@553: (because all of the data is replicated everywhere), a single bos@553: cheap server can handle the needs of a much larger team, and bos@553: replication to balance load becomes a simple matter of bos@553: scripting. bos@553: bos@553: If you have an employee in the field, troubleshooting a bos@553: problem at a customer's site, they'll benefit from distributed bos@553: revision control. The tool will let them generate custom bos@553: builds, try different fixes in isolation from each other, and bos@553: search efficiently through history for the sources of bugs and bos@553: regressions in the customer's environment, all without needing bos@553: to connect to your company's network. bos@553: bos@553: bos@553: bos@553: bos@553: Why choose Mercurial? bos@553: bos@553: Mercurial has a unique set of properties that make it a bos@553: particularly good choice as a revision control system. bos@553: bos@553: It is easy to learn and use. bos@553: It is lightweight. bos@553: It scales excellently. bos@553: It is easy to bos@553: customise. bos@553: bos@553: If you are at all familiar with revision control systems, bos@553: you should be able to get up and running with Mercurial in less bos@553: than five minutes. Even if not, it will take no more than a few bos@553: minutes longer. Mercurial's command and feature sets are bos@553: generally uniform and consistent, so you can keep track of a few bos@553: general rules instead of a host of exceptions. bos@553: bos@553: On a small project, you can start working with Mercurial in bos@553: moments. Creating new changes and branches; transferring changes bos@553: around (whether locally or over a network); and history and bos@553: status operations are all fast. Mercurial attempts to stay bos@553: nimble and largely out of your way by combining low cognitive bos@553: overhead with blazingly fast operations. bos@553: bos@553: The usefulness of Mercurial is not limited to small bos@553: projects: it is used by projects with hundreds to thousands of bos@553: contributors, each containing tens of thousands of files and bos@553: hundreds of megabytes of source code. bos@553: bos@553: If the core functionality of Mercurial is not enough for bos@553: you, it's easy to build on. Mercurial is well suited to bos@553: scripting tasks, and its clean internals and implementation in bos@553: Python make it easy to add features in the form of extensions. bos@553: There are a number of popular and useful extensions already bos@553: available, ranging from helping to identify bugs to improving bos@553: performance. bos@553: bos@553: bos@553: bos@553: Mercurial compared with other tools bos@553: bos@553: Before you read on, please understand that this section bos@553: necessarily reflects my own experiences, interests, and (dare I bos@553: say it) biases. I have used every one of the revision control bos@553: tools listed below, in most cases for several years at a bos@553: time. bos@553: bos@553: bos@553: bos@553: Subversion bos@553: bos@553: Subversion is a popular revision control tool, developed bos@553: to replace CVS. It has a centralised client/server bos@553: architecture. bos@553: bos@553: Subversion and Mercurial have similarly named commands for bos@553: performing the same operations, so if you're familiar with bos@553: one, it is easy to learn to use the other. Both tools are bos@553: portable to all popular operating systems. bos@553: bos@553: Prior to version 1.5, Subversion had no useful support for bos@553: merges. At the time of writing, its merge tracking capability bos@553: is new, and known to be complicated bos@553: and buggy. bos@553: bos@553: Mercurial has a substantial performance advantage over bos@553: Subversion on every revision control operation I have bos@553: benchmarked. I have measured its advantage as ranging from a bos@553: factor of two to a factor of six when compared with Subversion bos@553: 1.4.3's ra_local file store, which is the bos@553: fastest access method available. In more realistic bos@553: deployments involving a network-based store, Subversion will bos@553: be at a substantially larger disadvantage. Because many bos@553: Subversion commands must talk to the server and Subversion bos@553: does not have useful replication facilities, server capacity bos@553: and network bandwidth become bottlenecks for modestly large bos@553: projects. bos@553: bos@553: Additionally, Subversion incurs substantial storage bos@553: overhead to avoid network transactions for a few common bos@553: operations, such as finding modified files bos@553: (status) and displaying modifications bos@553: against the current revision (diff). As a bos@553: result, a Subversion working copy is often the same size as, bos@553: or larger than, a Mercurial repository and working directory, bos@553: even though the Mercurial repository contains a complete bos@553: history of the project. bos@553: bos@553: Subversion is widely supported by third party tools. bos@553: Mercurial currently lags considerably in this area. This gap bos@553: is closing, however, and indeed some of Mercurial's GUI tools bos@553: now outshine their Subversion equivalents. Like Mercurial, bos@553: Subversion has an excellent user manual. bos@553: bos@553: Because Subversion doesn't store revision history on the bos@553: client, it is well suited to managing projects that deal with bos@553: lots of large, opaque binary files. If you check in fifty bos@553: revisions to an incompressible 10MB file, Subversion's bos@553: client-side space usage stays constant The space used by any bos@553: distributed SCM will grow rapidly in proportion to the number bos@553: of revisions, because the differences between each revision bos@553: are large. bos@553: bos@553: In addition, it's often difficult or, more usually, bos@553: impossible to merge different versions of a binary file. bos@553: Subversion's ability to let a user lock a file, so that they bos@553: temporarily have the exclusive right to commit changes to it, bos@553: can be a significant advantage to a project where binary files bos@553: are widely used. bos@553: bos@553: Mercurial can import revision history from a Subversion bos@553: repository. It can also export revision history to a bos@553: Subversion repository. This makes it easy to test the bos@553: waters and use Mercurial and Subversion in parallel bos@553: before deciding to switch. History conversion is incremental, bos@553: so you can perform an initial conversion, then small bos@553: additional conversions afterwards to bring in new bos@553: changes. bos@553: bos@553: bos@553: bos@553: bos@553: Git bos@553: bos@553: Git is a distributed revision control tool that was bos@553: developed for managing the Linux kernel source tree. Like bos@553: Mercurial, its early design was somewhat influenced by bos@553: Monotone. bos@553: bos@553: Git has a very large command set, with version 1.5.0 bos@553: providing 139 individual commands. It has something of a bos@553: reputation for being difficult to learn. Compared to Git, bos@553: Mercurial has a strong focus on simplicity. bos@553: bos@553: In terms of performance, Git is extremely fast. In bos@553: several cases, it is faster than Mercurial, at least on Linux, bos@553: while Mercurial performs better on other operations. However, bos@553: on Windows, the performance and general level of support that bos@553: Git provides is, at the time of writing, far behind that of bos@553: Mercurial. bos@553: bos@553: While a Mercurial repository needs no maintenance, a Git bos@553: repository requires frequent manual repacks of bos@553: its metadata. Without these, performance degrades, while bos@553: space usage grows rapidly. A server that contains many Git bos@553: repositories that are not rigorously and frequently repacked bos@553: will become heavily disk-bound during backups, and there have bos@553: been instances of daily backups taking far longer than 24 bos@553: hours as a result. A freshly packed Git repository is bos@553: slightly smaller than a Mercurial repository, but an unpacked bos@553: repository is several orders of magnitude larger. bos@553: bos@553: The core of Git is written in C. Many Git commands are bos@553: implemented as shell or Perl scripts, and the quality of these bos@553: scripts varies widely. I have encountered several instances bos@553: where scripts charged along blindly in the presence of errors bos@553: that should have been fatal. bos@553: bos@553: Mercurial can import revision history from a Git bos@553: repository. bos@553: bos@553: bos@553: bos@553: bos@553: CVS bos@553: bos@553: CVS is probably the most widely used revision control tool bos@553: in the world. Due to its age and internal untidiness, it has bos@553: been only lightly maintained for many years. bos@553: bos@553: It has a centralised client/server architecture. It does bos@553: not group related file changes into atomic commits, making it bos@553: easy for people to break the build: one person bos@553: can successfully commit part of a change and then be blocked bos@553: by the need for a merge, causing other people to see only a bos@553: portion of the work they intended to do. This also affects bos@553: how you work with project history. If you want to see all of bos@553: the modifications someone made as part of a task, you will bos@553: need to manually inspect the descriptions and timestamps of bos@553: the changes made to each file involved (if you even know what bos@553: those files were). bos@553: bos@553: CVS has a muddled notion of tags and branches that I will bos@553: not attempt to even describe. It does not support renaming of bos@553: files or directories well, making it easy to corrupt a bos@553: repository. It has almost no internal consistency checking bos@553: capabilities, so it is usually not even possible to tell bos@553: whether or how a repository is corrupt. I would not recommend bos@553: CVS for any project, existing or new. bos@553: bos@553: Mercurial can import CVS revision history. However, there bos@553: are a few caveats that apply; these are true of every other bos@553: revision control tool's CVS importer, too. Due to CVS's lack bos@553: of atomic changes and unversioned filesystem hierarchy, it is bos@553: not possible to reconstruct CVS history completely accurately; bos@553: some guesswork is involved, and renames will usually not show bos@553: up. Because a lot of advanced CVS administration has to be bos@553: done by hand and is hence error-prone, it's common for CVS bos@553: importers to run into multiple problems with corrupted bos@553: repositories (completely bogus revision timestamps and files bos@553: that have remained locked for over a decade are just two of bos@553: the less interesting problems I can recall from personal bos@553: experience). bos@553: bos@553: Mercurial can import revision history from a CVS bos@553: repository. bos@553: bos@553: bos@553: bos@553: bos@553: Commercial tools bos@553: bos@553: Perforce has a centralised client/server architecture, bos@553: with no client-side caching of any data. Unlike modern bos@553: revision control tools, Perforce requires that a user run a bos@553: command to inform the server about every file they intend to bos@553: edit. bos@553: bos@553: The performance of Perforce is quite good for small teams, bos@553: but it falls off rapidly as the number of users grows beyond a bos@553: few dozen. Modestly large Perforce installations require the bos@553: deployment of proxies to cope with the load their users bos@553: generate. bos@553: bos@553: bos@553: bos@553: bos@553: Choosing a revision control tool bos@553: bos@553: With the exception of CVS, all of the tools listed above bos@553: have unique strengths that suit them to particular styles of bos@553: work. There is no single revision control tool that is best bos@553: in all situations. bos@553: bos@553: As an example, Subversion is a good choice for working bos@553: with frequently edited binary files, due to its centralised bos@553: nature and support for file locking. bos@553: bos@553: I personally find Mercurial's properties of simplicity, bos@553: performance, and good merge support to be a compelling bos@553: combination that has served me well for several years. bos@553: bos@553: bos@553: bos@553: bos@553: bos@553: Switching from another tool to Mercurial bos@553: bos@553: Mercurial is bundled with an extension named convert, which can incrementally bos@553: import revision history from several other revision control bos@553: tools. By incremental, I mean that you can bos@553: convert all of a project's history to date in one go, then rerun bos@553: the conversion later to obtain new changes that happened after bos@553: the initial conversion. bos@553: bos@553: The revision control tools supported by convert are as follows: bos@553: bos@553: Subversion bos@553: CVS bos@553: Git bos@553: Darcs bos@553: bos@553: In addition, convert can bos@553: export changes from Mercurial to Subversion. This makes it bos@553: possible to try Subversion and Mercurial in parallel before bos@553: committing to a switchover, without risking the loss of any bos@553: work. bos@553: bos@553: The convert command bos@553: is easy to use. Simply point it at the path or URL of the bos@553: source repository, optionally give it the name of the bos@553: destination repository, and it will start working. After the bos@553: initial conversion, just run the same command again to import bos@553: new changes. bos@553: bos@553: bos@553: bos@553: