Mercurial: The Definitive Guide
Bryan O'Sullivan
Language: English
Pages: 284
ISBN: 0596800673
Format: PDF / Kindle (mobi) / ePub
This instructive book takes you step by step through ways to track, merge, and manage both open source and commercial software projects with Mercurial, using Windows, Mac OS X, Linux, Solaris, and other systems. Mercurial is the easiest system to learn when it comes to distributed revision control. And it's a very flexible tool that's ideal whether you're a lone programmer working on a small project, or part of a huge team dealing with thousands of files.
Mercurial permits a countless variety of development and collaboration methods, and this book offers several concrete suggestions to get you started. This guide will help you:
- Learn the basics of working with a repository, changesets, and revisions
- Merge changes from separate repositories
- Set up Mercurial to work with files on a daily basis, including which ones to track
- Get examples and tools for setting up various workflow models
- Manage a project that's making progress on multiple fronts at once
- Find and fix mistakes by isolating problem sources
- Use hooks to perform actions automatically in response to repository events
- Customize the output of Mercurial
Mercurial: The Definitive Guide maintains a strong focus on simplicity to help you learn Mercurial quickly and thoroughly.
hello.c. This updates the working directory so that it contains changes from both heads, which is reflected in both the output of hg parents and the contents of hello.c: $ hg parents changeset: user: date: summary: 5:cbfc9ee6ea99 Bryan O'Sullivan
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
copy, we must use the -C option to hg status to see that the added file is really being tracked by Mercurial as a copy of the original, now removed, file. $ hg status -C A b a R a As with hg remove and hg copy, you can tell Mercurial about a rename after the fact using the --after option. In most other respects, the behavior of the hg rename command, and the options it accepts, are similar to the hg copy command. If you’re familiar with the Unix command line, you’ll be glad to know that the hg
is a highly successful, well-regarded piece of software. Pull-Only Versus Shared-Push Collaboration A perpetual source of heat in the open source community is whether a development model in which people only ever pull changes from others is “better than” one in which multiple people can push changes to a shared repository. Typically, the backers of the shared-push model use tools that actively enforce this approach. If you’re using a centralized revision control tool such as Subversion, there’s
has the worst compression ratio, but is widely used in the Windows world. If you provide an empty list, or don’t have an allow_archive entry at all, this feature will be disabled. Here is an example of how to enable all three supported formats. [web] allow_archive = bz2 gz zip • allowpull: Boolean. Determines whether the web interface allows remote users to hg pull and hg clone this repository over HTTP. If set to no or false, only the “human-oriented” portion of the web interface is available.