It is known fact among developers that VCS (version control system) or SCM (source code management) are good for team developing, it helps syncing each developer code changes into one final product, while effectively resolving code conflicts. But how can it helps loners ?
In the ages of CVS or modern SVN using such a tool was pain in the ass. It required to install and configure one central server, where all repos (source code repositaries) would exists, create user logins, passwords, upload project to the server, manage permissions. There was absolutely no point to do this for just yourself.
Nowadays source code management moved far beyond, very popular and advanced Distributed SCMs eliminated all complexity and added many cool features. There are some to choose.
When 4 years ago I was on the crossroad, I tried Mercurial, because at that time it has good Linux AND Windows support, nice interface called MercurialHG and it was one of the three best tools available (git,bzr,hg).
I am not going to cover basic ideas and usage, plz referrer to guides on the net, there are a lot. I want to concentrate on my topic and it give you some advantages I use in my daily developing.
Easy to use
How to move current project under Mercurial control ?
$cd my_project # Init repo in current folder $hg init # Add all files recursively $hg add # Initial comment $hg commit
3 commands, thats it! All other features are not any difficult.
This is the most obvious strong point, so it is the beginning of my list. Code repository acts as a backup of all versions of your software. When you need to extract version “0.11-beta” it is already there and was not lost. If you have rewritten some proc and not happy with the result, you can roll back.
Using MercurialHG make viewing code history an easy task.
At the ages of CVS, the word “brunch” was your brightest nighmare (:, but time changed. Branches are easy and fun to play with, especially in Mercurial.
Let me show an example how to branching: You are developing project and almost instantly roll new features into production on live server. Once you’ve got a task that requires 2-3 days to complete and some major rewrites in underlying data or business logic layer. After 1 day of developing your boss asks you to fix very urgent bug, your actions ? Your current development environment code is messed up.
Without SCM: Try to fix bug on live server OR copy live to development, fix there and upload to live. Not to forget to include this fix in your current development code or it will be lost on next deployment.
Mercurial way: Before new feature implementation your clone your repository, making an exact copy, it is called branch. Working in that branch does not affect main project folder, you can continuously fix all bugs and work in new feature. After new feature is done, you just PUSH changes back to main folder and Mercurial will do all the dirty job of correct merging.
# Clone project folder with one command $hg clone project proj_feature1 # make changes $cd project_feature1 $eclipse # Push changes back $hg push # Update source priject $cd ../project1 $hg update
And thats all 🙂
Once your code is under SCM it is easy to setup several places of development (work, home) and sync changes between these places. One marvelous feature of Mercurial is that you can share your repository at every moment, via SSH or HTTP(S). Sharing allows you to create one location available on the Net and push and pull changes from there.
It is even possible to take changes with you on flash drive using Mercurial bundle command.
Usage of Mercurial helps in project deployment. Once you changed lots of files on the project, uploading to the server may be long. Having Mercurial repo on the server reduces the effort to commands:
# Commit changes locally $hg commit # Push them to the server in compressed format $hg push # Update the server $hg update
In this case it is very easy to rollback your changes in case everything went wrong.
Thats it! Feel free to leave feedback in comments.My Google Profile+