This review is based on hands-on lab tests. The scope of products reviewed is limited to popular tools that are PC-based (run standalone at least on MS Windows), support projects, and offer a graphical user interface. The four products included are:
We have made an effort to be accurate and complete. Please let us know if you discover any unintentional mistakes or inaccuracies, or if you would like to submit comments to be added to the review (make sure you provide detailed information to back your claims/comments).
Our goal in this evaluation is to be objective about the capabilities of each tool, but at the same time, we want to provide a subjective and opinionated commentary that will raise questions and issues of value for those who are trying to select the right version control product for their projects.
This approach is an attempt to complement product information available from vendors and users, and to overcome their limitations. Vendors are too vested (who can blame them) and have been known to stretch reality. Users, on the other hand, tend to be either a bit religious (if they are happy and want to be seen as a hero in their organization), or in witch-hunt mode (if they are unhappy and need to cover their back for things not working well).
This discussion assumes that you are already familiar with the basic concepts and terminology of version control.
In this review we are concerned with how each product addresses:
All four products provide well seasoned version control solutions. Each shines in certain areas and is weaker in others. To help you weight strengths and weaknesses against your needs and priorities we start with a discussion of product architecture, followed by a description of how each product addresses the vendor control issues listed above. A brief review of each product concludes the document. In each review we include a profile of what we consider the ideal user, or soft spot, for the product. Keep in mind that, given the many factors that impact a product selection, these profiles are, by necessity, a generalization.
PC-based products can be broken down in two major architectures: file-based (first generation), and project repository based (second generation).
PVCS and Source Integrity have a first generation, file-based architecture. This combines individual file archives with a layer of project meta data. File archives can be scattered in a number of directories on a LAN. They store each file version and its meta data (labels, user name, date and time of change, status, etc.). Information about the structure and status of projects is maintained in the project meta data layer. Operations on projects and files require that information be collected and synchronized from both file archives and project layer.
Through the years, these products have grown considerably in functionality from simple file version control utilities to more sophisticated products that support projects and promotions. The project layer, as well as their graphical user interface, have been relatively recent additions.
CCC/Manager and Visual SourceSafe employ a second generation architecture that is project repository based. This approach integrates both project and file meta data in a central and cohesive database that was designed from the ground up to support entire projects and their evolution in time. A second generation architecture also provides the ideal foundation for implementing file sharing and process management.
All four products track changes to any type of file (source code, documentation, binaries). Changes to text files are stored in reverse deltas (complete latest version, plus differences to recreate previous versions) by PVCS, Source Integrity, and SourceSafe. CCC/Manager uses forward deltas (complete first version plus differences to create later versions). The obvious advantage of reverse deltas is that it is faster to access the most current versions. Forward deltas save some storage space when there are many lines of descent in a delta tree. Binary files are stored in compressed format. At the level of tracking changes to individual files we do not detect any major advantage or disadvantage between the products.
First we need to look at how easily you can organize your project files in an arbitrary hierarchy of directories. All products support this with the exception of PVCS. PVCS's project assistant gives the impression that a hierarchy of directories is supported, but in fact, creates a flat structure of directories with hierarchical names. SourceSafe and CCC/Manager support recursive commands through a project hierarchy. Source Integrity only supports this in the command line interface (CLI) and PVCS only supports it in the graphical user interface (GUI).
SourceSafe is unique in its ability to control multiple projects in the same database. You can browse all projects in a single view, collapsing or expanding the display at any level. The other products only support a single project view. Both SourceSafe and Source Integrity support sub-projects, or the ability to include a project in another project. This is particularly useful when working on larger systems where sub-systems are developed by different groups, but each group needs access to the complete code base for builds and testing.
It is not uncommon to change the way files are organized in a project. For example, in release-2 you may have several files under a sub-directory, and in release-3 you may decide to break them up into two more sub-directories. When you go back to release-2 you should see the project structure as it was then and find the files in their place, so you can do maintenance changes when needed. At the same time, in release-3 you would see the new structure. In either release you should have the complete history of changes, across releases for each file. And comparing the two releases should indicate what files and directories had been moved, deleted, or renamed.
Now let's look at reality. In CCC/Manager you see the different structures in each release, but there is no link between the same file in release-2 and release-3 (i.e., foo.c in release-3 would look like a new file). In Source Integrity and PVCS the difference in structure is also recorded, but trying to access a file in release-2 that has been moved in release-3 results in an error message indicating that the archive is no longer there. SourceSafe, thanks to its repository approach, is able to keep track of project structure changes and retain the link in version history for files that have been moved.
As projects evolve through different releases and variants for maintenance and ports, each product provides mechanisms for identifying each release and recreating it. However, the way this is done varies considerably. CCC/Manager requires users to decide up front what release they are working on, and all changes are made in the context of that release (configuration). A file history in CCC/Manager is limited to the changes made in each configuration. The plus of this approach is that it is very easy to click on a release and see exactly what is in it. The minus is that it is hard to see the global evolution of a file across releases.
PVCS, SourceSafe, and Source Integrity identify releases through labels and by versioning projects. This approach offers more flexibility, but makes recreating a prior release more involved. In PVCS and Source Integrity the only way to recreate a prior release or baseline is by "getting" a copy of the files with the required label. This makes a copy of the files in your working directory. SourceSafe is the best of the three in this area, because it lets you create a copy of a project version (release) through its file sharing mechanism (discussed next) within the SourceSafe repository, without forcing you to create an external copy.
File sharing is important to support both the reuse of code across different applications, and to leverage the commonality between different releases and variants of a project. File sharing is a unique feature of SourceSafe. In the case of different applications sharing code SourceSafe gives the flexibility to see the code being shared right in your project hierarchy, and it gives you the option to lock it at a given version, or keep it dynamically updated from the original project. If you need to, you can branch off and make your own changes. Shared files have a unique icon to distinguish them from non-shared files.
Source Integrity's support for sub-projects gives you a similar capability to SourceSafe's file sharing. But it lacks the range of sharing functions, and checks and bounds that makes SourceSafe a more complete offering in this area.
To perform maintenance changes, or create variants of a project is simply a matter of sharing the entire project and modifying the files that need to be changed. CCC/Manager also supports this by creating virtual copies of an existing configuration. PVCS and Source Integrity support this through branching and labeling.
Once again we have two approaches. CCC/Manager and SourceSafe view branching as a function that takes place within the context of different versions of a project. If you wanted to do maintenance on a release, you would make a copy of the release (virtual configuration in CCC, and shared project in SourceSafe) and start making changes. The products do the branching for you.
PVCS and Source Integrity do branching at the individual file level. You would branch off each file at the appropriate level in the version tree, and label your new versions accordingly.
The first approach gives you automatic context, but does not give you a view of the complete file version tree, making it more difficult to understand the evolution of each file. The second approach puts on you the onus to manage branching and ensuring that through labels you will be able to see changes in the right context. But it gives you a complete history of each file's version tree. It is too bad that it has to be either one or the other. A combination of both is very feasible and would be ideal.
PVCS, Source Integrity, and SourceSafe have a visual differences function (side-by-side comparison with color coded highlights of changes and conflicts). CCC/Manager only supports a text-based difference.
Source Integrity stands out as the only product with a very nice visual merge tool. However, the tool is not well integrated with the version control tool and leaves it up to the user to figure out what to do with the merged file.
None of the merge tools are very intuitive and well integrated. It is typically hard to determine which branches are candidates for merging, or what to do with the results. This is definitely an area of functionality that is very critical and begs for improvements.
All four products support working directories in which to check out files and make changes. Source Integrity's Sandboxes have the nice feature of letting users know when newer versions of a file are available in the archives, so they can decide if they want to update their sandbox.
PVCS and Source Integrity provide similar mechanisms for defining promotion levels for files and projects. Source Integrity is a bit friendlier in that it automatically demotes a previously promoted file version if it is checked out and in again. However, their approach is very impractical at the individual file level and should be used only at the project level. If you are sharing file archives in different projects things could get very messy if different projects apply potentially different promotion models to the same file. Also, these products do not let you view a project baseline based on promotion level unless you "get" a copy of the project files to a working directory. This could become quickly out of synch with what is taking place in the archives. Therefore, we view this approach as little more than a specialized use of labels.
CCC/Manager implements lifecycles by creating a "virtual configuration" from a given release for each promotion stage. Changes are first made in the development configuration, then copied to the testing configuration, and finally to the new release configuration. You can easily see what changes are in which promotion stage, but there is a lot of duplicate storage, no complete version tree view, and the potential for a messy situation when a change that is below the top version needs to be demoted or undone.
SourceSafe does not support promotions.
Change packages are a natural extension of promotions. Typically, a given bug fix or enhancement requires changes to multiple source or header files, documentation, and test cases. Also, some changes depend on each other. Change packages allow you to group all related files, and all related changes in logical units that can be operated on as a whole to ensure that all components are promoted together.
CCC/Manager is the only one of the four products discussed here that supports change packages.
PVCS has by far the most sophisticated security options. SourceSafe and CCC/Manager have adequate support for security, and Source Integrity relies on a NetWare Loadable Module to take advantage of Novell's security. While it would be nice for Source Integrity to have their own security beyond the file level, one has to consider their argument that PVCS's approach may be sophisticated when people use PVCS, but it leaves the file archives very vulnerable when accessed directly.
Pre- and post-event triggers allow an organization to tailor the behavior of a tool to match its own policies and procedures. For example, you may want to automatically notify the test manager when changes are promoted to testing. An event trigger for the promote function would accomplish this.
PVCS and Source Integrity support triggers on some of their commands. CCC/Manager and SourceSafe do not have triggers.
Source Integrity includes a make utility. CCC/Manager and PVCS offer it as an optional product. SourceSafe targets Visual Basic and Visual C++ environments that have their own build tools, therefore it does not support builds and dependencies.
We have not conducted a hands-on evaluation of the make tools but they appear to be fairly comparable. PVCS also supports footprinting, which is like a Bill-of-Materials of all the components that created an executable, or build target.
A CLI is very important for scripting (batch files), macros, and remote access. CCC/Manager supports only two CLI commands: check-out and check-in. PVCS has major inconsistencies between CLI and GUI (projects are not supported in the CLI). Source Integrity has some minor inconsistencies (some CLI options are missing in the GUI). SourceSafe's CLI is consistent with the GUI.
Likes and dislikes of GUIs are very subjective, so here is our not-so-humble opinion. Overall SourceSafe has the most functional, consistent, and intuitive GUI. If only it showed a complete version tree with branches and merges it would be hard to beat. Being able to browse multiple projects and easily share code between them is great. Too bad one cannot edit a checked-out file directly from the GUI.
PVCS has a great Folders view that lets you go down to the history of each file, including labels and promotions, without having to bring up a different view. This makes working with files very straightforward (except for all the confirmation messages that pop up). The assistants (project, merge, and difference) are more confusing than helpful, and in general, the product is fairly complex to setup and learn.
Source Integrity's GUI looks like a simple transposition of commands to a Windows environment. The functionality is there, but it's not pretty and does not deliver what we have come to expect from a GUI. The result is an inflation of views that do not appear to be automatically synchronized.
CCC/Manager also suffers from view inflation. A detail that we found very frustrating was that some functions require the user to explicitly refresh the view in order to see the results of the function just performed.
CCC/Manager caters more to the needs of configuration and release managers, than to developers. Therefore, we see this product as an ideal tool for environments in which developers get a copy of the files they need, work in their own directories, and when they are done they "throw their changes over the wall" for the CM folks to move them through a formal approval and release cycle.
If you maintain legacy applications and require gateways to mainframe host systems, PVCS is your choice. The extensive support for security and promotions points to a good match for larger and more formal organizations. And the wide availability of interfaces to PVCS makes it a good choice where different departments use different development tools, but want a common version control system.
Source Integrity has a good range of functionality that gels together well. We see it as a great product for smaller teams of technical developers that are not dependent on a GUI and do not need security beyond the file level.
Teams that operate in an informal culture, use Visual Basic or Visual C++, and share code between applications are ideal candidates for Visual SourceSafe. The simplicity and intuitiveness of the product also make it a good fit for organizations that do not want to invest a lot of time and training on CM, but require a good CM safety net.
We hope that this document has helped you gain a better understanding of the products evaluated here, their strengths, weaknesses, and the differences in how they approach and implement version control.
In summary, if control is your mantra, you should look at products like PVCS and CCC/Manager. If flexibility is your priority, SourceSafe and Source Integrity are a better match.
Please give us your feedback and let us know what you liked and what you would improve in this document, so that we can make it more useful for other CM professionals.
Alex Lobba
tel. 805/563-1369 - fax 805/563-6021
E-Mail: [email protected]
Last Updated: 05/17/96 - Copyright ©1996 Alex Lobba