 | |
|
Technology news and Jobs 
The Linux distillery Compiling and contributing to the Linux/open source subversion
The Linux distillery Compiling and contributing to the Linux/open source subversion | Compiling and contributing to the Linux/open source subversion |
|
| by David M Williams | |
| Monday, 03 December 2007 | |
|
Page 1 of 3 Version control software – and let’s call it VCS from here on – enforces that code be “checked out” and back in again. Traditionally, only one person can check out a module at a time. This means that one extremely common risk is mitigated immediately, namely the problem where two programmers independently change the same source code file, and whoever saves first loses their mods completely when the second person saves. Using this type of VCS the second person cannot check out the file if somebody has already checked it out. You can think of checking a file out as being similar to checking a book out of a library. Obviously, nobody else can borrow that book if it has been taken out. It must be returned. However, there is one fundamental difference. Checking a file out of a VCS does not remove it. Any number of people can still request a copy of the file, as it was when last checked in. This is good because it permits other programmers or interested parties to get a copy of the source code at any time. These parties will not be able to put any modifications back into the VCS, though. Only the person with the checked out file can submit their modifications, and they do this when they check the file back in. At that time, the VCS updates its version count for the file, includes the new code, and makes the file available to be checked out again, whether by the same programmer as before or someone else, and whether it happens straight away or months or years later. Other VCS systems have a different way of thinking; in a complex project it’s unjustifiable to lock a whole file even if someone is working on just one function in it. So, these VCS systems allow the code to be checked out by anyone and then merge all updates that come back in to maintain a seamless single code base despite when and where changes occur. In this case, think of the safety tag system in use at industrial sites; you don’t dare turn a piece of equipment on if somebody has a safety tag on it. However, there’s nothing stopping many people putting their own safety tag on the equipment because they need to work on it too. They all work on different parts, and remove their own tag when they finish. At the completion of the work, many people have performed actions (or made changes) and these have effectively been “merged” into a single whole. Best of all, the version control system maintains a record of what has been altered when a file is checked back in. The developer is encouraged to write a helpful annotation describing, at a high-level, the purpose for their modifications but even without this the system can reconstruct any previous version and show exactly what differs between it and any other version, be it the latest or not. |
| < Next story in category | Previous story in the category > |
|---|
