Mercurial

Setting up Mercurial

We are using 1.0.1 of Mercurial right now. This is in the Ubuntu 8.04 backports!

apt-get install mercurial meld

Put something like this into your ~/.hgrc file:

[ui]

username= Keith Curtis <keithcu@gmail.com>

editor=gedit

merge=meld

Note: We only have 1.9 gigs of free disk space right now, so be careful not to waste it.

In the root of your repo is a hidden .hg directory with a complete history.

Also there is a .hgignore file. I made it filter out the pesky .svn directories. Feel free to add other types.

We have Repo!

Web interface: http://keithcu.com/cgi-bin/hg.cgi

Connect to Repo

hg clone http://keithcu.com/cgi-bin/hg.cgi YOURLOCALDIRNAME

To add files (This recurses, so clean out your binaries first)

hg add *

To update files

Just write to the files

hg diff

hg commit (Type some description text on the top line and save and quit)

To get up to date with server

hg pull (downloads, but doesn't apply them)

May need hg merge, hg commit sometimes. Fill in if you figure it out!

hg update (applies them)

To push your committed changes up to server

hg push

I have unauthenticated push! Don't tell your hacker friends about our secret repo! ;-)

Why use Mercurial?

Mercurial is written in Python, is distributed has a solid community, has young code, etc. Bzr is built by Ubuntu, and does have some momentum, but I think Mercurial should and will win. Git is used by Linux but is considered complicated and has other downsides (see Git wikipedia article for a list of them.)

The biggest difference from a client/server VCS (ala svn) to a distributed one is the idea that branches are used a lot more. In svn, branches are used when you want to do some long-term development on something. But in a distributed VCS you create one for every individual bug that you are working on. This provides a nice level of isolation between disparate thing you might be working on. Because of all this branching, distributed VCSs try to make branching a cheap operation.

And one way to make branching cheap is to do it locally. The "distributed" part of these tools comes from the fact that they are designed to work offline. This lets you commit changes and such to your local disk without requiring Internet access to hit a central repository online (but you can commit your changes to an online repository later when you are ready to). This is really handy if you develop on a laptop; it really sucks to have to do a bunch of coding remotely and then commit one huge patch instead of committing a bunch of individual patches. You want the atomicity of commits that represent a single piece of semantic change to allow better tracking of how/why your code changed, not some blob of code that changes a bunch of things at once. Plus it allows for easier rollback if you accidentally introduced a bug. From [1]