Why use code version control for solo developing ?

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.

Code history

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.

Easy branching

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 🙂

Multiple location

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.

Deployment

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.

1 comment

  1. The main difference is that there is enltseialsy no main server; at least not necessarily. You can push and pull to and from any git repository without losing any history. You always have a local repository containing all the history and when you push the changes to a central server (it is possible to have one) you push all the commits you did locally, not just the current state the project is in.Of course, it’s still a SCM, so in many ways it’s similar to subversion. It has some cool extra features like the ability to cherry pick changes from a single commit from someone else’s branch, for instance a bugfix. It’s also apparantly better at resolving conflicts and keeping the repository sane, but I don’t really have any personal experience on that end yet.

Leave a Reply

Your email address will not be published.