Source Code Version Control Solutions - The Basics
(Page 2 of 4 )
Version control suites are composed of a server daemon (service) and numerous clients. The main centralized revision control server acts as a file-server that keeps copies of the managed folders and files. It's called a repository. Each repository contains file-system trees in their entirety, and maintains its own structure (directories, files, etc.).
Clients can access this repository, download the files, apply their own modifications, and so forth. As I mentioned, until this point, a version control suite acts like a file server. But the real beauty of version control systems comes from their so-called revisioning or versioning model. Think about it: what happens if more than one person wants to work at the same time on the same file? The system must manage these situations.
As a matter of fact, the above scenario is the founding principle behind SCM/VCS solutions. They all try to solve this conflicting scenario. The earliest approach, which isn't at all popular nowadays, was quite simple. It was called the "lock-modify-unlock" solution. In short, the first user was served first because he or she locked the file until completing his or her work on it, and unlocked it at the end.
This approach avoided conflicting situations, but it wasn't effective, because it prohibited other developers working on the file. They were left waiting in line instead of being productive. So productivity took a huge hit. And let's not even mention situations where the first developer, the one that locked the file(s), forgot to release the locks! Only system administrators could fix things when this situation almost inevitably occurred.
As you may imagine, this approach was replaced by a more advanced "copy-modify-merge" solution. This starts out with the mindset that all of the developers should have a local copy of the repository (parts of it, at least) on which they were planning to work. So it begins with copying from the repository to their systems.
Once this is done, they can then work on the files. There were no conflicting issues until this point on the centralized repository. Everybody could work on the same files locally without any problems whatsoever. The most complex part is at the end, the so-called merging event. As soon as developers finish their work, it's time to synchronize the files with the repository, applying the updates. This is done via "intelligent" merging.
Let me explain. In those cases where the changes do not overlap, such as one of the developers edited the beginning of the file, while the other worked on the bottom, then the changes are applied without any conflicts. But when the changes overlap each other, this is what we call a conflicting situation, and then version control systems aren't "intelligent" enough to decide. Thus, ultimately, a developer will decide.
This means that the file(s) become(s) flagged as being conflicting, and both of the changes are presented to developers (preferably, the last one that was working on them). Then the developer is able to manually edit the file once again, apply the changes, figure out the situation, alleviate the conflict, and save the resolved solution to the repository.
The latter approach does not give a sense of false security, as does the traditional one described earlier. Back then you'd have thought that once the file is locked, it is safe. In large projects, many of the files are designed to work with and between each other, and thus, an incompatibility can very easily happen. But when a human decides what to do in case there is a conflict, then we can safely assume that he or she makes the right decision. If not, there are earlier revisions to which we can revert..
Both CVS and Subversion, the open-source revision control systems that we'll present on the next page, are based on the "copy-modify-merge" approach. Clients can sync with the repository to download a local copy of project(s), work on them, and ultimately publish their changes (merging and/or solving conflicts, if need be). Also, clients can be notified when the file(s) they are working on becomes out-of-date.
The two aforementioned source management models are often called file locking and version merging. However, for the purpose of this article, we've opted for the "lock-modify-unlock" and "copy-modify-merge" terms because they are much more expressive. Kudos goes to the original Subversion Book.
One final theoretical concept that should be mentioned is that revision control systems track the entire "lifetime" of projects, meaning they record the timestamps of modifications that happen, as well as manage earlier revisions. These additional administrative files and information are created and recorded by the system without user interference. It's all automatic. It should be noted that project files are tracked with revision numbers.
Next: A Few Solutions >>
More Server Administration Articles
More By Barzan 'Tony' Antal
