This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Desktop Software

Introducing Mercurial, a distributed version control system

By Amit Kumar Saha on November 20, 2007 (9:00:00 AM)

Share    Print    Comments   

According to its developers, "Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects." Dozens of projects already use the software. Here's how you can get started with some basic version control tasks using Mercurial.

Mercurial is a open distributed version control system. According to Wikipedia, distributed revision control takes a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository with which clients synchronize, each peer's working copy of the codebase is a bona fide repository. Synchronization is conducted by exchanging changesets, which define unique versions of every file, from peer to peer.

Mercurial is good for version control of both personal projects and large-scale enterprise projects.

Installing Mercurial is a breeze. Download the Mercurial tarball, extract the archive, change to the mercurial directory, and run:

$ make
$ sudo make install    # do a system-wide install
$ hg debuginstall      # sanity check
$ hg                   # see help

See the software's Web site for detailed installation instructions and platform-specific notes.

To begin exploring Mercurial, you can work with an existing repository or set up your own. To initialize a new local repository with the name "f00-repo," use the command hg init f00-repo. Note that I said "initialize," not "create"; if the directory already exists, hg initializes a new repository there. Otherwise, Mercurial creates a directory named .hg and then initializes it. Mercurial keeps all the metadata about the repository in this directory.

Once you have a repository, you can tell Mercurial about a file you want to track with the command hg add file1.txt. When you're satisfied with the file, check it in with a comment using a command like hg commit -m "Added new file".

You can view a log of your transactions by using the hg log command:

$ hg log
changeset:   0:4706e1104b96
tag:         tip
user:        amit@ubuntu-laptop
date:        Sun Nov 04 22:31:28 2007 +0530
summary:     Added new file

Cloning and pulling

If you want to create a working copy of a repository for yourself in which you can create, modify, and commit files before you commit them to the parent repository (so that you can keep working even when you are disconnected from the remote repository, or you just want experiment with the code), you can clone an existing repository, specifying the original and your new repository names:

$ hg clone f00-repo f00-repo-1
2 files updated, 0 files merge d, 0 files removed, 0 files unresolved

Other users can do the same thing, leading to disparate versions of files in diverse repositories on the server or the network. Suppose that John's working copy is f00-repo-1 and Jane's is f00-repo-2. If Jane wants to "pull" in the changes that John committed, she can first determine what things will be pulled with the following command:

$ hg incoming ../f00-repo-1
comparing with ../f00-repo-1
searching for changes
changeset:   3:5b2454e51e13
user:        amit@ubuntu-laptop
date:        Sun Nov 04 23:43:30 2007 +0530
summary:     Added file2

changeset:   4:8503fe7d3247
user:        amit@ubuntu-laptop
date:        Sun Nov 04 23:44:01 2007 +0530
summary:     Added file3

changeset:   5:5a26319e7c66
tag:         tip
user:        amit@ubuntu-laptop
date:        Sun Nov 04 23:48:28 2007 +0530
summary:     Added 1 line each

To pull in the changes and update the working copy, she would run:

$ hg pull ../f00-repo-1
pulling from ../f00-repo-1
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 4 changes to 4 files
(run 'hg update' to get a working copy)

$ hg update
4 files updated, 0 files merged, 0 files removed, 0 files unresolved

Pushing

If, once she's made changes, if Jane wants to pass them along to another user, she can push her changes into someone else's repository. Again, the first step is to check what will be pushed:

$ hg outgoing ../f00-repo-3
comparing with ../f00-repo-3
searching for changes
changeset:   3:5b2454e51e13
user:        amit@ubuntu-laptop
date:        Sun Nov 04 23:43:30 2007 +0530
summary:     Added file2

changeset:   4:8503fe7d3247
user:        amit@ubuntu-laptop
date:        Sun Nov 04 23:44:01 2007 +0530
summary:     Added file3

changeset:   5:5a26319e7c66
tag:         tip
user:        amit@ubuntu-laptop
date:        Sun Nov 04 23:48:28 2007 +0530
summary:     Added 1 line each

$ hg push ../f00-repo-3
pushing to ../f00-repo-3
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 4 changes to 4 files

If you're concerned about access control, Mercurial has you covered in threeways:

Remote repositories and other version control systems

Our discussions so far, has dealt only with local repositories. With remote repositories, nothing changes except the repository locations. You just have to specify a URL, which could be a remote Web server, an FTP server, or a domain name.

For example, to clone a remote repository, use the command:

$ hg clone http://selenic.com/hg working-rep0

Mercurial offers tools that provide automatic conversion of repositories from other SCMs to Mercurial. ConvertExtension bundled with mercurial supports branches, incremental imports, and only understands CVS, subversion, Darcs and git. This link will be useful for further information on the topic.

Help is never far away. The project has mailing lists and commercial support available. If you need further help, the book Distributed Revision Control with Mercurial is an excellent resource to have. The Mercurial Web site also lists some HOWTOs.

Conclusion

Mercurial is easy to set up, fast, and lightweight -- as good for your local version control needs as it is for maintaining large projects. Even going public with your repository is not a big hassle -- free Mercurial hosting is available.

Amit Kumar Saha is a student of computer science and engineering from India. He writes about Linux, open source software, and technical topics mainly for beginners, and is also a contributor to a couple of open source documentation projects.

Share    Print    Comments   

Comments

on Introducing Mercurial, a distributed version control system

Note: Comments are owned by the poster. We are not responsible for their content.

Why is it better than Subversion?

Posted by: Anonymous [ip: 198.240.213.26] on November 20, 2007 12:11 PM
We already have version control systems. Why do we need yet another one? Most free-software developers use Subversion; what is the benefit of losing time to learn a different one?

#

Re: Why is it better than Subversion?

Posted by: Anonymous [ip: 117.99.31.151] on November 20, 2007 12:23 PM
Choice- thats what Open Source gives you. Just as you think SVN is cool, there will be lots of people who will swear by CVS and and may be as many will say 'Mercurial' is here to stay. You just have to try it to see if its for you!

#

Re(1): Why is it better than Subversion?

Posted by: Anonymous [ip: 117.99.31.151] on November 20, 2007 12:25 PM
'Distributed' - is the keyword

#

Re: Why is it better than Subversion?

Posted by: Anonymous [ip: 192.163.20.232] on November 21, 2007 08:48 AM
Most people just use what's around. What is most commonly around is CVS or Subversion. I think far more code is still developed with CVS than SVN for the "its there" reason. We've had basically the same revision control packages since the 70s - SCCS, RCS, CVS (which is basically a front end to RCS), SVN (which is just CVS reimplemented, with no real benefits). Various commercial packages have come, and often gone, but stiill brought nothing really new.

Finally people are starting to move beyond these early crude packages. The older control systems really hamper people's style, and provide very poorly for distributed working, and experimental branching. People live in fear of refactoring, or even simple mass replacing poorly chosen variable or function names. Guiding development around the needs of the revision control system is a really sad way of working.

Mercurial, git, and commercial packages like Bit Keeper are finally trying to address the way modern development works. They are attempts to make revision control a support tool, instead of a straight jacket. Time will tell how successful they have been. However, you might notice from the growing list of major projects using these tools that people are eager to put a lot of effort into trying something new.

#

Re: Why is it better than Subversion?

Posted by: Anonymous [ip: 142.106.134.39] on November 21, 2007 05:13 PM
FIrst, it's a distributed version control system. That means that rather than have one repository and many child repositories it can host a complete hierarchy or repositories that can also be geographically dispursed. There is thus no 'central' repository and each repo has it's own version of the history of the contents. See http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated

More differences can be found here: http://hgbook.red-bean.com/hgbookch1.html#x5-180001.6

#

How do I do repositories on a FTP server?

Posted by: Anonymous [ip: 92.226.198.164] on November 20, 2007 01:22 PM
You said that it is possible to create repositories on a FTP server but I can't find any documentation on it. Is it really possible?

#

Re: How do I do repositories on a FTP server?

Posted by: Anonymous [ip: 117.99.18.66] on November 20, 2007 02:01 PM
Yes, try doing ftp://your-repo-url. Please comment back in case you face problems.

#

Re(1): How do I do repositories on a FTP server?

Posted by: Anonymous [ip: 85.176.231.170] on November 24, 2007 12:10 PM
C:\Programme\xampp\htdocs\obsessive>hg clone ftp://username:password@my-server.de/hg/cms/ cms2
abort: repository ftp://username:password@my-server.de/hg/cms/ not found!

#

Re(2): How do I do repositories on a FTP server?

Posted by: Anonymous [ip: 67.180.129.169] on November 25, 2007 05:33 PM
Did you already create a repository on that ftp site?

#

Why not Git?

Posted by: Anonymous [ip: 75.72.96.53] on November 20, 2007 02:23 PM
Git already supports distributed version control with tags, like Mercurial. However, Git also supports lightweight branching in which an individual developer's repository can contain multiple branches. Mercurial seems to require separate repositories to achieve the same thing, which isn't as nice.

Mercurial is still a big step up from Subversion, but it seems Git is an even better choice.

#

Re: Why not Git?

Posted by: Anonymous [ip: 169.233.25.105] on November 20, 2007 03:57 PM
Yeah! Go git 'em!

#

Re: Why not Git?

Posted by: Anonymous [ip: 63.113.210.11] on November 20, 2007 06:23 PM
How well does Git run on Windows? ;-)

#

Re(1): Why not Git?

Posted by: Anonymous [ip: 10.10.10.254] on November 21, 2007 03:44 AM
Apparently it's almost there. http://kerneltrap.org/Linux/Git_on_Windows

If that is the only reason everyone is not using git... well, I hope you're ready to switch when msysGit is done ;-)

#

Re: Why not Git?

Posted by: Anonymous [ip: 142.106.134.39] on November 21, 2007 05:14 PM
From http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn:

"A little exploration turned up that Linus' git stuff is a bit wonky in a lot of ways. It's a few c programs surrounded by a slew of scripts of varying quality, and not many tools for. Mercurial, on the other hand, tackles the same problems, but is written in Python, well supported, well documented and seems to have a lot of momentum in the OSS community.

#

Re: Why not Git?

Posted by: Anonymous [ip: 83.166.220.63] on November 26, 2007 10:17 AM
No, it doesn't require separate repos for multiple branches. See http://hgbook.red-bean.com/hgbookch8.html or http://www.selenic.com/mercurial/wiki/index.cgi/NamedBranches

#

Re: Why not Git?

Posted by: Anonymous [ip: 213.31.222.18] on November 26, 2007 10:28 AM
"even better..." hmm.

I want to depend on my SCM tool, see it maintained, evolved, supported on all platforms, integrated with all IDEs. This is a critical piece of my toolchest.

From what I understand, GIT is maintained for Linux, supported for kernel development, and integrated with vi. From my understanding this is all that Linux cares about.

Even if a Windows version is "near", what about all the other stuff? Eclipse integration. Integration with task trackers e.g. Trac. Scalability to multiple inter-related projects.
Windows support is just one piece out of many.

In the end the future will tell which was a better choice. Currently I trust Mercural more than GIT for being the universal, flexible, and powerful tool that I want.

#

Re(1): Why not Git?

Posted by: Anonymous [ip: 210.212.4.227] on November 27, 2007 08:39 AM
Yes, you also have a Mercurial Plugin for NetBeans. :-)

#

message was spam

Posted by: Anonymous [ip: 85.98.47.206] on December 03, 2007 07:38 PM
-->deleted
[Modified by: Anonymous on December 08, 2007 08:23 AM]

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya