13

I have just begun working on a project which uses Mercurial as a version control system, and I need some basic tips on how to use this. Please use this question to give some introductory tips on this technology.

Especially, I am looking for tips on the best programs to use and the best techniques to use (branches, in and out-checking etc. I need to learn the best-practices!)

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Espen Herseth Halvorsen
  • 6,175
  • 7
  • 36
  • 38

7 Answers7

14

Here is a helpful tutorial on Mercurial written by Joel Spolsky.

It covers basic usage and commands, as well as how to work with Mercurial at a more conceptual level. If you are already familiar with SVN, then the first part is definitely worth reading: it talks about the major conceptual differences between SVN and Mercurial, because trying to use Mercurial in the same way that you use SVN is asking for trouble.

David Johnstone
  • 24,300
  • 14
  • 68
  • 71
  • 1
    This tutorial is absolutely amazing, so clear and easy to understand. Just what I needed as someone completely new to DVCSs and Version Control in general. – Acorn Apr 28 '10 at 12:58
  • Most probably you're right to warn against the use of Mercurial as if it was SVN, but for many basic operations this is still possible. And extensions like *hgsubversion* (see https://bitbucket.org/durin42/hgsubversion/overview/) even suggest this is perfectly valid. Nevertheless special features including *Mercurial Queues* (http://mercurial.selenic.com/wiki/MqExtension) unleash the real power of Mercurial, and you miss it before you familiarize yourself with these features. – hasienda Dec 18 '11 at 21:22
14

I know you already have the Mercurial site but the resource most useful to me was the Mercurial book. It's an excellent overview of the program and how to use it.

I found the best way to learn Mercurial was just to use it on a project. I imported into Mercurial a project I had exported from subversion and did some regular development with it. I made sure to clone the repository for different changesets so that I could get used to the merging and updating. I haven't learned all of the advanced uses but I'm now on a pretty firm footing with it and haven't switched back to Subversion yet.

A lot of projects have different techniques for commit workflow. Some have changes pushed from the developers, like centralized systems, and some will pull the changes from contributors (Linux, for example). It's hard to generalize too much without knowing the process for your project.

This is how I do my development:

  • Centralized tree on a file share or http, called project-trunk or project that is the definitive project version
  • A clean tree on my system that I clone from the remote repository and use to push back to the repository. I then clone from this tree for my changes. I call this tree project-local
  • Clone the project-local tree for each of my changes: eg. project-addusers, project-141, etc.
  • After I am finished with the commits to a tree, I then push the changes to the project-local repository
  • Finally, push the changes in the project-local to project-trunk

I have the clean project-local tree because then I can push all the changesets back to the trunk at one time, which is helpful if there is a group of related changes that need to push back together.

As for tools, it depends on your platform. I just use the vanilla command line tool. Coming from TortoiseSVN, it was a bit of a change to go to the command line. But I'm fine with it now. I tried using TortoiseHg but it didn't function well on my Windows 7 x64 virtual machine. I hear it's much better on the supported 32-bit platforms.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Steven Lyons
  • 8,138
  • 1
  • 28
  • 27
  • The book has gotten better with it's most recent iteration, and is mature enough to have been published in hard-copy. If you are reading this, and are still looking for a Mercurial starting point, it's definitely the place to start. – quark Jul 25 '09 at 05:32
  • 1
    As an added bonus you can find the source for the book in a Mercurial repository on BitBucket: http://bitbucket.org/bos/hgbook. Which means you can make edits and present them to the author, using the tool itself. – quark Jul 25 '09 at 05:36
5

Have a look at the Mercurial book, or at this Mercurial tutorial.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Charlie Martin
  • 110,348
  • 25
  • 193
  • 263
2

If you use the latest TortoiseHG client and include the install directory in your PATH environment, you will be able to use both the nice GUI they provide, and the command line 'hg'

I cannot recommend using the mq extensions too much. They make for a great 'working repository' environment.

I use the queues to manage local changes against a subversion repository. I do my local short term changes and use mercurial to keep in sync with subversion and the rest of the team.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
John Weldon
  • 39,849
  • 11
  • 94
  • 127
2

Depending on your background with other source control tools, I would also suggest a specific SCM-whatever to Mercurial guide. For example, have a look at this guide for Subversion users.

Another good resource for getting your head around the whole "distributed" source control idea is: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ ... with helpful diagrams!

akent
  • 4,068
  • 28
  • 27
1

A few of Steve Losh's blog posts are good, even though they're a couple of year old now. They mainly deal with how to work with branching.

It's also worth looking at his hgtip.com site.

Paul S
  • 7,645
  • 2
  • 24
  • 36
0

In addition to the Mercurial Book and the Hg Init tutorial, I'll like to mention the example-driven guide I've written:

It shows how to get started with Mercurial and also covers some more advanced concepts such as named branches and hgsubversion. I've used it when teaching Mercurial to new users and they seemed to like it.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229