Transmission Line Noise

Ver­sion Con­trol Systems

Fri, Dec 18, 2009
GIT Version Control

Intro­duc­tion

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

Deploy­ment

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