Mercurial
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
Password:
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
ENV=~/.bashrc
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
fi
cat .bashrc
if [ -f ~/.profile ]; then
source ~/.profile
fi
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.