Prepare MacOS development machine for cloning

To be able to clone from my MacOS Lion based development machine I need to make hg work over SSH which don't work on freshly installed MacOS X client.

Test it by running ssh user@client hg --version from the server (you want to clone to) to the development client (you want to clone from).

# ssh peter@client hg --version
bash: hg: command not found

This is due to the way shell configuration files are being sourced which results in PATH is not setup correctly in non-interactive mode. See .bash_profile vs .bashrc for more info.

First make sure that .bashrc is called at ssh login. Create the following file.

$ cat ~/.ssh/environment 

I solve this by using .profile as my main configuration file. Because

cat .profile
export PATH=$PATH:/usr/local/bin

cat .bash_profile 
if [ -f ~/.bashrc ]; then
    source ~/.bashrc

cat .bashrc 
if [ -f ~/.profile ]; then
    source ~/.profile

Now hg should work over ssh.

Clone/pull repository over SSH

If you have made sure that hg works over the SSH connection a clone is a simple as this.

cd /var/www/pages/rails
hg clone ssh://peter@silver/Documents/hg/photogenic

To get updates to an existing cloned repository you may pull updates from server or development machine

cd /var/www/pages/rails/ops
hg pull ssh://peter@silver/Documents/hg/ops
hg update

Use a central server

To allow for multiple access or redundancy it is good to have a central repository where repositories are synched to. Synch can either be done from the server (via hg pull) or the clients (via hg push). Just make sure to clone the repository first as described above.

Stop tracking files

If you want to stop tracking of a file you can forget the file.

hg forget <file>

The file will remain locally but will not be tracked in future revisions.

Merge separate development

It is quite straight forward to merge changes between difference repositories. If the repositories are located on the same computer the process is done as follows.

Move the the first project.

cd project

Check what changes is expected from a pull from a secondary project. This is just informative.

hg incoming ../another/project

Perform the pull from the secondary project. Make sure that secondary project has committed all changes that you are expecting to pull.

hg pull ../another/project

Now the version tree has two heads (one from each repository). Local files still hasn't changed in first project. You can confirm this by.

hg heads

To actuall perform merge between the heads do hg merge.

hg merge

You will need to resolv unresolved merges interactively. On Windows using TortoiseHg this will bring up KDiff3 to resolve the conflicts. If you need to resolve some files after merge you can do this with hg resolve

hg resolve <file>

After merge has completed (with no unresolved files) you finally need to commit the changes.

hg commit

Very intuitive actually.