Source Code Version Control Solutions - A Few Solutions
(Page 3 of 4 )
Let's begin with one of the earliest revision control systems: Concurrent Versions System-the CVS. It was developed in the early 1980s and was the leading choice of many open source projects over the years. The source management model is the latter version-merging approach, which goes like this: the user "checks out" (gets a local copy), works on the project files, and then "checks in" to upload his or her changes.
One of its features limits developers to "checking in" only the latest releases. Keep in mind that project files may become out of date during the time that a developer is working on them. If this happens, then he or she is required to "check out" to grab the latest files, see what has happened, apply the changes manually, figure out everything, and then seamlessly "check in," saving the changes. This provides reliability.
Extensive logging is also included, along with the revision numbers (which are incremented after each change), notes regarding who has authored the files, and such. Ultimately, branching support isn't neglected-this means there's the possibility to have various branches (release candidate, stable release, beta release, bug fixes, etc.).
It should be noted that CVS, just like any other version control system, uses an efficient compression method called delta compression. Since usually source codes are in some form of text file (meaning, not binary), this is useful. Moreover, during transactions only the "changes" are communicated, reducing network workload. The "changes" are figured out via the revision numbers and/or checksums.
For more extensive documentation, please check out the official user manual.
There are various implementations, modifications, and enhancements of the classic CVS-like version controlling, especially because it is open source. One of the major variations seems to be OpenCVS, but right now it's still under heavy development. Check it out-at the time of writing, the release ought to be coming "soon." This release plans to fix the security issues CVS has been facing (because it's been stagnant for years).
As promised at the beginning of this article, it's time to present Subversion, also known as the SVN. The original purpose of this product was to become better than CVS by adding those "must-have" features that the earlier software lacked. SVN was first released in 2000, and it's been continuously updated ever since by CollabNet.
Talking about the features of Subversion means we'll be comparing it a lot with CVS. It's a CVS on steroids, sporting most, if not all, of the traditional CVS features. Many of these were updated too. But on top of those, Subversion provides a lot of additional enhancements. For a detailed features list, please head over to the official site.
Subversion also takes a unique approach, offering both file locking ("lock-modify-unlock") and version merging ("copy-modify-merge") solutions. Basically, you can flag files as "locked" if that's what you want, but by default this isn't done; nor should it be endorsed, unless really necessary. SVN's interoperability and API have been completely revamped and redesigned from scratch.
Next: Going Commercial and Concluding Thoughts >>
More Server Administration Articles
More By Barzan 'Tony' Antal
