Mercurial_ The Definitive Guide - Bryan O'Sullivan [20]
If you omit an explicit revision, hg update will update to the tip revision, as shown by the second call to hg update in the example above.
Pushing Changes to Another Repository
Mercurial lets us push changes to another repository from the repository we’re currently visiting. As with the example of hg pull above, we’ll create a temporary repository to push our changes into:
$ cd ..
$ hg clone hello hello-push
updating working directory
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
The hg outgoing command tells us what changes would be pushed into another repository:
$ cd my-hello
$ hg outgoing ../hello-push
comparing with ../hello-push
searching for changes
changeset: 5:12efb75cbece
tag: tip
user: Bryan O'Sullivan date: Tue May 05 06:44:49 2009 +0000 summary: Added an extra line of output And the hg push command does the actual push: $ hg push ../hello-push pushing to ../hello-push searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files As with hg pull, the hg push command does not update the working directory in the repository that it’s pushing changes into. Unlike hg pull, hg push does not provide a -u option that updates the other repository’s working directory. This asymmetry is deliberate: the repository we’re pushing to might be on a remote server and shared between several people. If we were to update its working directory while someone was working in it, their work would be disrupted. What happens if we try to pull or push changes and the receiving repository already has those changes? Nothing too exciting: $ hg push ../hello-push pushing to ../hello-push searching for changes no changes found Default Locations When we clone a repository, Mercurial records the location of the repository we cloned in the .hg/hgrc file of the new repository. If we don’t supply a location to hg pull from or hg push to, those commands will use this location as a default. The hg incoming and hg outgoing commands do so too. If you open a repository’s .hg/hgrc file in a text editor, you will see contents like the following: [paths] default = http://www.selenic.com/repo/hg It is possible—and often useful—to have the default location for hg push and hg outgoing be different from those for hg pull and hg incoming. We can do this by adding a default-push entry to the [paths] section of the .hg/hgrc file, as follows: [paths] default = http://www.selenic.com/repo/hg default-push = http://hg.example.com/hg Sharing Changes over a Network The commands we have covered in the previous few sections are not limited to working with local repositories. Each works in exactly the same fashion over a network connection; simply pass in a URL instead of a local path: $ hg outgoing http://hg.serpentine.com/tutorial/hello comparing with http://hg.serpentine.com/tutorial/hello searching for changes changeset: 5:12efb75cbece tag: tip user: Bryan O'Sullivan date: Tue May 05 06:44:49 2009 +0000 summary: Added an extra line of output In this example, we can see what changes we could push to the remote repository, but the repository is understandably not set up to let anonymous users push to it: $ hg push http://hg.serpentine.com/tutorial/hello pushing to http://hg.serpentine.com/tutorial/hello searching for changes ssl required Starting a New Project It is just as easy to begin a new project as to work on one that already exists. The hg init command creates a new, empty Mercurial repository: $ hg init myproject This simply creates a repository named myproject in the current directory: $ ls -l total 12 -rw-rw-r-- 1 bos bos 47 May 5 06:44 goodbye.c -rw-rw-r-- 1 bos bos 45 May 5 06:44 hello.c drwxrwxr-x 3 bos bos 4096 May 5 06:44 myproject We can tell that myproject is a Mercurial repository, because it contains a .hg directory: $ ls -al myproject total 12 drwxrwxr-x 3 bos bos 4096 May 5 06:44 . drwx------ 3