manager has a large software development project; the development staff is onboard, planning is complete, and now it is time
to turn the programmers loose to put the plan into action. Would it be helpful to have a software solution to help store and
maintain the code that these programmers write, rewrite, and debug? What if it could also track all changes, maintain the
code in a single repository, and provide the ability to build the product from a single location? Source code version control
software does all this, and more.
Many organizations structure their projects so that individual programmers have responsibility for particular segments of the
product. These developers often maintain their individual source code and supporting software on their own computer system.
When it comes time to produce a releasable version of the product, each programmer must put his or her segment of the product
into a centralized directory on a common machine for final compilation. This scenario has many pitfalls:
Lost source code due to
- Aggressive code refactoring resulting in overly complex and buggy code
- Accidental file and directory deletions
- Hardware failure
- Stolen computers
- Recent backups unavailable
Halted development when the programmer is absent or unavailable
- The only copy of the source code is on the programmer's laptop, which is with the absent programmer
- The programmer's machine is in the office, but the login and password is unknown preventing access to source code
- Several versions of the source code exist in multiple directories - which is the most current version?
- Even if someone finds the source, how does the absent developer normally build it - from the IDE, through scripted
routines, or another specialized process?
Lack of history
- No way to identify the reason for the code change. Did the change fix a specific bug, add new features, or was it a major
- No way to know exactly what changed in the previous version of the source code, making it difficult to locate and fix a
Lack of code synchronicity
- The project is compromised when built with incompatible versions of interdependent modules
- Conflicts arise when multiple developers modify the same source code without knowledge of each other's changes
Version control software effectively addresses all of these potential pitfalls and plays an important role in any
comprehensive software development cycle. Perusing the internet reveals thousands of open-source projects that are stored in
Concurrent Versions Control (CVS) archives. The CVS system manages the source
code changes, even with thousands of programmers modifying the code on the same project. Quality source code control allows
multiple developers around the world to work simultaneously on a common software project and is the method with which the
open source community develops such popular software packages as Linux, FreeBSD, and Apache.
Put simply, version control software keeps a history of the changes made to a set of files. For developers, that means being
able to keep track of all the changes made to a program during its development cycle. There are many version control systems
to choose from such as SoftLanding's PVCS Version Manager, Microsoft's Visual SourceSafe, and CVS, the system BASIS uses. The
brand of version control system chosen depends on the development environment, size of the project, and feature set. While
version control systems all provide the fundamental ability to track changes, they can differ in other areas - such as the
method used to access files. Exclusive locks and shared access are the two most common file access methods.
Exclusive Locks: A checked out file is available only to the person who checked it out.
In other words, when a programmer checks out a file, he or she is the only one who can modify the file in the same way books
in a library are available only to the person who checks them out. Once the programmer checks the files back in, other
developers can access the files. This access method, however, has its drawbacks. For example, if a developer forgets to check
in file changes over a weekend, these files are unavailable to other developers who may need to make additional
modifications. Fortunately, there are administrative tools that overcome these situations but it can still be a problem from
time to time.
Shared Access: Multiple developers have simultaneous modification access to the same
file(s). When the developer checks in their working copy, CVS merges the updates from their copy with what is in the archive.
Most of the time developers modify separate sections of the code so there are no conflicts. However, during the rare times
when two developers change the same lines of code, CVS handles this cautiously. It puts the modifications from the archive
and your modification to the same lines into your local copy of the file, with annotations that identify the conflicts. CVS
merely identifies the conflict, relying on the developer to resolve the issue.
At BASIS, the central software archive resides on a UNIX machine and the developers access it either from other UNIX, Linux,
or Windows machines using the built-in client/server access methods. CVS supports various platforms for both the clients and
Some of the more powerful concepts and functions that CVS offers include:
Checkout the process of checking out a copy of one or more files from the archives to a local computer. Developers can check
out a single file, a module consisting of several files, or the entire archive at a designated version. The ability to check
out different versions allows a developer to build the product from various stages in its life, regardless of how many files
other developers added, deleted, or changed in the interim.
Branching the ability to freeze source code at a specific point in the archive process. Branching allows part of the
development team to continue developing future changes/ enhancements in the main line of the archive while another part of
the team makes changes that only apply to the branch. The branch keeps the two development projects separate, however, it is
possible to merge a branch back into the main line later, if desired. Because of this, branching makes it possible to setup a
"skunkworks" project development scenario and either discard it or merge the changes into the main project.
Branching also provides reproducibility, allowing developers to "go back in time" and check out source code as it existed at
any point. This makes it possible to recreate a previous version of the product, regardless of the number of subsequent
changes, additions, or deletions to the project. The BASIS IDET creates a graphical representation of the history of all
changes to a file and its branches, as displayed in Figure 1.
Figure 1. Graphical display from the BASIS IDE of the lifetime versioning of a file
Tag the user-defined name assigned to a specific revision of a file(s). Tagging may more intuitively identify a particular
version of a file. A developer will more readily remember the tag than an obscure date or the lengthy revision as shown in
Figure 2. CVS log shows the generated log message, user-defined tag(s), revision, and time stamp for that version
Log the overview of the changes (see Figure 2) made to a particular file without having to peruse the code. When checking
in changes to a file, developers provide a description of the work done. These descriptions give an overview of the changes,
or perhaps even mention which bugs or defect numbers the code changes address. Viewing the log of changes makes it easy to
see what modifications occurred in the file and why, without having to look at the individual lines of the source code.
Diff the comparison between two different revisions of a program. This allows the developer to determine when, where, and
who corrected a problem, added a new feature, or introduced a particular bug into the source code.
Since a complete archive of a project contains multiple versions of many files, one might conclude that CVS stores a full
copy of each file and requires a significant amount of hard disk space. Fortunately, this is not the case. CVS stores the
initial ASCII file in its entirety and then, in subsequent revisions, only tracks the changes. Storing these incremental
changes dramatically reduces the storage requirements for the archive.
It is difficult to complain about the price of CVS because it is free! The BASIS IDE is also free and includes an integrated
CVS client, simplifying the developer's ability to use CVS for all BASIS products. Whether developing a project in PRO/5®,
Visual PRO/5®, or BBj®, CVS gives the programmer the ability to maintain safe and accurate version control from within the
BASIS IDE. This is just one more reason why the BASIS IDE is the tool of choice for BBx development.
Figure 3 shows the BASIS IDE and these integrated CVS client features:
Figure 3. BASIS IDE showing CVS client features
||Mounted CVS archive (displays file status modified (+) or updated ( ), revision number, and branch),
||File branch structure (with "diff" dialog to easily select two versions of a file to compare), and
||The actual "diff" (highlights the changed text in the two versions).
Considered a safety net, a version control system provides recovery opportunities and peace of mind throughout the
development cycle. Confidence and security may be the greatest benefits a version control system delivers.