Mercurial

Setting up Mercurial

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. I have access to more but my total is 12 gigs It is mirrored and stuff, but storage is expensive on VPS right now. Torcs has 500 megs of car and track stuff, for example.

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]