• Choose a category
• All
• Classic-Fiction

drwxrwxr-x 3 bos bos 4096 May 5 06:44 .hg

If we want to add some pre-existing files to the repository, we copy them into place and tell Mercurial to start tracking them using the hg add command:

$ cd myproject

$ cp ../hello.c .

$ cp ../goodbye.c .

$ hg add

adding goodbye.c

adding hello.c

$ hg status

A goodbye.c

A hello.c

Once we are satisfied that our project looks right, we commit our changes:

$ hg commit -m 'Initial commit'

It takes just a few moments to start using Mercurial on a new project, which is part of its appeal. Revision control is now so easy to work with, we can use it on the smallest of projects that we might not have considered with a more complicated tool.

Chapter 3. A Tour of Mercurial: Merging Work

We’ve now covered cloning a repository, making changes in a repository, and pulling or pushing changes from one repository into another. Our next step is merging changes from separate repositories.

Merging Streams of Work

Merging is a fundamental part of working with a distributed revision control tool. Here are a few cases in which the need to merge work arises:

Alice and Bob each have a personal copy of a repository for a project they’re collaborating on. Alice fixes a bug in her repository; Bob adds a new feature in his. They want the shared repository to contain both the bug fix and the new feature.

Cynthia frequently works on several different tasks for a single project at once, each safely isolated in its own repository. Working this way means that she often needs to merge one piece of her own work with another.

Because we need to merge often, Mercurial makes the process easy. Let’s walk through a merge. We’ll begin by cloning yet another repository (see how often they spring up?) and making a change in it:

$ cd ..

$ hg clone hello my-new-hello

updating working directory

2 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ cd my-new-hello

# Make some simple edits to hello.c.

$ my-text-editor hello.c

$ hg commit -m 'A new hello for a new day.'

We should now have two copies of hello.c with different contents. The histories of the two repositories have also diverged, as illustrated in Figure 3-1. Here is a copy of our file from one repository:

$ cat hello.c

/*

* Placed in the public domain by Bryan O'Sullivan. This program is

* not covered by patents in the United States or other countries.

*/

#include

int main(int argc, char **argv)

{

printf("once more, hello.\n");

printf("hello, world!\");

printf("hello again!\n");

return 0;

}

And here is our slightly different version from the other repository:

$ cat ../my-hello/hello.c

/*

* Placed in the public domain by Bryan O'Sullivan. This program is

* not covered by patents in the United States or other countries.

*/

#include

int main(int argc, char **argv)

{

printf("hello, world!\");

printf("hello again!\n");

return 0;

}

Figure 3-1. Divergent recent histories of the my-hello and my-new-hello repositories

We already know that pulling changes from our my-hello repository will have no effect on the working directory:

$ hg pull ../my-hello

pulling from ../my-hello

searching for changes

adding changesets

adding manifests

adding file changes

added 1 changesets with 1 changes to 1 files (+1 heads)

(run 'hg heads' to see heads, 'hg merge' to merge)

However, the hg pull command says something about “heads.”

Head Changesets

Remember that Mercurial records what the parent of each change is. If a change has a parent, we call it a child or descendant of the parent. A head is a change that has no children. The tip revision is thus a head, because the newest revision in a repository doesn’t have any children. There are times when a repository can contain more than one head.

Figure 3-2. Repository contents after pulling from my-hello into my-new-hello

In Figure 3-2, you can see the effect of the pull from my-hello into my-new-hello. The history that was already present in my-new-hello