Transmission Line Noise

Ver­sion Con­trol Systems

Fri, Dec 18, 2009
GIT Version Control


Just some overview notes on the subject.

Which VCS?

There are many vcs’s around both free and paid for. The type of VCS while impor­tant is not as impor­tant as actu­ally using. From the sin­gle devel­oper up to big teams there is no way you should be cod­ing with­out a VCS.

There are cen­tralised sys­tems such as Sub­ver­sion where the project is held on a cen­tral server and devel­op­ers check out and in and deploy­ments are made from this cen­tral repository.

Then there are dis­trib­uted sys­tems, DVCS’s, such as Mer­cu­r­ial and GIT. With these the devel­oper has a local repos­i­tory, does all the devel­op­ment, check­ing in and out locally and when appro­pri­ate will push changes to another remote repos­i­tory to be merged.

See the end of this post for var­i­ous links

Some of the points to be kept in mind when using VCS’s

  • A VCS does not replace com­mu­ni­ca­tion between mem­bers of a team
  • Clear processes and guide­lines on how to use the sys­tem need to be in place, espe­cially when, as you inevitably will, break them to help recover gracefully.
  • Read the book. SVN, GIT and Mer­cu­r­ial have books online that are free to read or down­load. They don’t have to be read from cover to cover and can be skimmed to get a feel for which is the right one for you.
  • Before doing any­thing mod­er­ately com­plex take a backup of the repos­i­tory. That way you can blow it away and start again with­out shaft­ing your repository.

Branch­ing Merg­ing and Tagging

In SVN the prac­tice is to have three direc­to­ries, Trunk, Tags and Branch. For DVCS’s the con­ven­tions are some­what dif­fer­ent but I am going with the SVN nomen­cla­ture to sim­plify things.

  • The trunk is always the ver­sion that you would go live with.
  • Tags are one off snap­shots of the trunk and are not used for fur­ther development.
  • Branches are for devel­op­ment work. A copy of the repo is taken and worked on. Dur­ing the life of the branch updates can be made from the Trunk if say bugs are fixed on the Trunk to keep the ver­sion in sync.
  • At some point the Branch will be merged back into the Trunk, which will be fraught with pain and angst but at least you will have the tools and the abil­ity to see what you are doing roll back.
  • Once this is done the branch is left but not used again and a new Branch made for the next level of development.

For DVCS’s the pic­ture is sim­i­lar as a process but dif­fer­ent in exe­cu­tion. Here the repos­i­to­ries can be cloned in total and worked on as a branch and then merged locally and then again merged with the remote/master repository


Devel­op­ment is done on local machines, checked out, worked on checked in or merged and then the deployed to the test envi­ron­ment (you do have a test envi­ron­ment don’t you?) and if it passes then deployed to the pro­duc­tion server. Ok that’s a sim­pli­fied ver­sion but some­thing along those lines.

  • Rule 1 Do not deploy directly from the repository
  • Rule 2 Do not deploy directly from the repository
  • Rule 3 well you get the idea.

Deploy to a stag­ing area and then to move to the test server or the live server by using shell script­ing that will con­sol­i­date, add, edit, alter the files and then deploy them automatically.

rsync is a highly effec­tive way of mov­ing files from one server to another and has a plethora of options such as –delete which will remove files from the tar­get server that have been deleted in the repos­i­tory, there­fore keep­ing the server uncluttered.

exclude which can be pointed to a file will allow you to exclude file, say con­fig files which dif­fer between test and development

it is also pos­si­ble that all the assets are not in the repos­i­tory. Stor­ing assets such as images do not scale well in ver­sion con­trol sys­tems because these files are already binary, so a minor change can mean the whole file is altered and then stored in the VCS. This can add sig­nif­i­cantly to the repos­i­tory size which will reduce its effec­tive trans­fer speed.

The other major advan­tages of script­ing the build is the speed of deploy­ment, the fact that you will make far less mis­takes espe­cially when you need to deploy under pres­sure. It allows you build unit tests in and it opens the route to con­tin­u­ous inte­gra­tion in the future.

GIT Man­ual

SVN Book

Mer­cu­r­ial Book