First page Back Continue Last page Graphics

Version Control


Notes:

I never did understand how the change control system was expected to work – a single branch maintained (in MKS) with around 20 developers committing changes.

When a piece of work was completed (which could take weeks) a form was completed indicating which revisions of which files were released into integration test.

Problems were common - it was possible to release a version of a file that depended on a later version of another file than that released to "testing". It was impractical to build past versions of the system (partly because the "version" was defined by a list if files and version numbers kept manually – and whose relationship to version control was tenuous.)

Because MKS didn't identify local files that were not under version control it wasn't easy to determine if the result of a check-in would compile.

Files were locked to individual developers – and a lot of (error prone) manual merging took place on some of the more popular files. Deadlocks happened.

The build broke on a regular basis – developers were reluctant to synchronise their work for fear of losing days sorting out the build.