Mercurial_ The Definitive Guide - Bryan O'Sullivan [13]
Making a Local Copy of a Repository
Copying a repository is just a little bit special. While you could use a normal file copying command to make a copy of a repository, it’s best to use a built-in command that Mercurial provides. This command is called hg clone, because it makes an identical copy of an existing repository.
$ hg clone http://hg.serpentine.com/tutorial/hello
destination directory: hello
requesting all changes
adding changesets
adding manifests
adding file changes
added 5 changesets with 5 changes to 2 files
updating working directory
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
One advantage of using hg clone is that, as we can see above, it lets us clone repositories over the network. Another is that it remembers where we cloned from, which we’ll find useful soon when we want to fetch new changes from another repository.
If our clone succeeded, we should now have a local directory called hello. This directory will contain some files.
$ ls -l
total 4
drwxrwxr-x 3 bos bos 4096 May 5 06:44 hello
$ ls hello
Makefile hello.c
These files have the same contents and history in our repository as they do in the repository we cloned.
Every Mercurial repository is complete, self-contained, and independent. It contains its own private copy of a project’s files and history. As we just mentioned, a cloned repository remembers the location of the repository it was cloned from, but Mercurial will not communicate with that repository, or any other, unless you tell it to.
What this means for now is that we’re free to experiment with our repository, safe in the knowledge that it’s a private “sandbox” that won’t affect anyone else.
What’s in a Repository?
When we take a more detailed look inside a repository, we can see that it contains a directory named .hg. This is where Mercurial keeps all of its metadata for the repository.
$ cd hello
$ ls -a
. .. .hg Makefile hello.c
The contents of the .hg directory and its subdirectories are private to Mercurial. Every other file and directory in the repository is yours to do with as you please.
To introduce a little terminology, the .hg directory is the “real” repository, and all of the files and directories that coexist with it are said to live in the working directory. An easy way to remember the distinction is that the repository contains the history of your project, while the working directory contains a snapshot of your project at a particular point in history.
A Tour Through History
One of the first things we might want to do with a new, unfamiliar repository is understand its history. The hg log command gives us a view of the history of changes in the repository.
$ hg log
changeset: 4:2278160e78d4
tag: tip
user: Bryan O'Sullivan date: Sat Aug 16 22:16:53 2008 +0200 summary: Trim comments. changeset: 3:0272e0d5a517 user: Bryan O'Sullivan date: Sat Aug 16 22:08:02 2008 +0200 summary: Get make to generate the final binary from a .o file. changeset: 2:fef857204a0c user: Bryan O'Sullivan date: Sat Aug 16 22:05:04 2008 +0200 summary: Introduce a typo into hello.c. changeset: 1:82e55d328c8c user: mpm@selenic.com date: Fri Aug 26 01:21:28 2005 -0700 summary: Create a makefile changeset: 0:0a04b987be5a user: mpm@selenic.com date: Fri Aug 26 01:20:50 2005 -0700 summary: Create a standard "hello, world" program By default, this command prints a brief paragraph of output for each change to the project that was recorded. In Mercurial terminology, we call each of these recorded events a changeset, because it can contain a record of changes to several files. The fields in a record of output from hg log are as follows: changeset: This field has the format of a number, followed by a colon, followed by a hexadecimal (or hex) string. These are