We have Repo!

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

To get it setup hg clone http://keithcu.com/cgi-bin/hg.cgi LOCALDIRNAME

= 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

To get up to date with server

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

To push your changes up to server

hg push

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

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

Important commands are located here: http://www.ivy.fr/mercurial/ref/v1.0/Mercurial-Usage-v1.0-120dpi.png

Publishing a respository

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]