Version control

Version control applies to anything you can store in a computer file or any other media that can be copied. It could be an image going through an editing process. The most common use in the Web is control of source code with the second use, and probably the more important use, is the control of published documents when people start arguing about the exact wording they read.

The simplest version control for a Web site is to build the Web site using Drupal and use the Drupal node verion control. You then solve the problem of deciding which version of a document was viewed on any given day.

The next level of expansion outwards is a CVS style version control were everything storable as a computer file goes into one system for a small level of control. Some proprietary version control systems add real control on top of the central system so you can assign files to specific people for priority action.

Bazaar, Git, Mercurial, and other distributed version control systems let you spread the workload over more people without them connecting to a central system. Those people can then delegate out to their team. You have no control over the spread of data outwards and have to battle to control the changed coming back in. Distributed version control works well when you have a big team with an agreed process for controlling and testing of the changes flowing back in.

Version control for source code, text files, and database creation SQL can apply to individual lines within text files. You can see the individual changes. You can edit hundreds of changes into a text file then see every difference. Version control rarely applies to edits within images because individual changes are merged into one final image by the editing program. You have to manually save the edited image at each major change if you want version control at that level of control.

Version control can apply to database entries to match code changes. You need external programs to record or extract individual changes to databases and store them in a form that can be stored as a file along side the code changes. When you example out across a whole series of applications, data, and files, you run into a lot of synchronisation problems. The main problem you get is recreating problems. Someone reports an error that occurred at 10:45. You try to record the difference between 10:44: and 10:46. Assuming you do mange to capture all the changes, you then try to replay the changes when testing improvements to your code. The changes can be difficult to replay without special database update utilities and related support utilities.

Often it is easier to write your own code to create test cases. The CVS application used to have an add on named ANT to apply those type of changes from XML based files but ANT just ran external programs and you ended up having to write programs. Version control rarely reduces the work required to test a code change. What version control does is make it easier for you to step back to an earlier version when your change does not work as planned.