Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Andy, In my previous job I was the administrator for MKS Source Integrity. One big advantage over raw CVS is that Source Integrity has the user interface built in. There is a command line available if you need to create batch files, but humans aren't forced to use it. In general, it is a more sophisticated system than CVS, having added a number of features to accommodate common idioms created in CVS by primitives. In CVS, a "project" tends to be defined by a directory tree. The files in that directory tree are either in the CVS project or they are in no project at all. If you have administrator privileges, I believe there are some tricks you can play with overlapping modules, but the average user is left out in the cold. Source Integrity takes the simple approach that a project is defined by a .proj text file. That file specifies the location of the repository (which can be anywhere) , the file names of all files in the project (wherever they may be in the file system), and the current tip revision number of each project file. This approach of project-defined-by-file rather than project-defined-by-directory has several advantages. * You can have a project that includes files in multiple directory trees. * You can have multiple projects in a single directory tree or even in a single directory. * Since the project is defined by a file, you can "version" your project. For example, instead of applying a tag to identify all file revisions in a new release (which involves opening/reading/writing/closing each file in many source control systems), you can merely checkin your project's .proj file. Since it includes the head revision numbers of all member files, you've effectively tagged the project. * Since projects are composed of files AND are defined by files, you have easily have a master project composed of files AND other [sub]projects. Those subproject can likewise have subprojects and so on. As a result, you can deal with you application as a single Source Integrity [master] project, or you can deal with the individual components of your application, or right on down to a project that is a single executable. All of these features are directly accessible to the Source Integrity GUI user and do not require intervention by the administrator to set up things on the server. Another feature I liked about Source Integrity was their equivalent of the CVS Update command. In CVS, it seems that you have to accept Update on blind faith. It will update your source tree with changes made in the repository, but it will also automatically merge your changes with those made by others (surprise, surprise). In Source Integrity, when you launch the GUI (or when you request comparison with the repository) files are tagged with icons indicating who has been changed. You can then request to see those changes, accept those change into your source tree, or keep your source tree as it is. Nothing happens behind your back. Merrill