We were asked to build a DOS/Windows/Unix-based version control system that provided all of the standard features of version control plus many other features that were ahead of their time, such as transparent archiving, branch merging, a graphical user interface and remote check in/out over the Internet.
An additional criterion was that controlled modules must always be kept in an intact, recoverable form and that recovery, in the event of something untoward (e.g. power failure during check-in), should be automatic. This goal was stated simply as, "The user of the product should never, ever lose anything." Despite setting such a high bar, the system's performance needed to be very good, as benchmarks against competing products would be used as a selling point.
The requirements dictated an architecture that supported journalling of all operations to the module storage area and that allowed automatic rollback to a known good point, in the event of a failure. The choice of how to store the versioned modules, although an architectural decision, would greatly affect the speed of the product so research into the best possible algorithm was done early on by BSM Development. Any tradeoffs between the reliability and speed goals were resolved in the architecture phase.
Since the product would have at least three user interfaces (basic command line, GUI and networked service), it was decided to architect it as a set of basic services (an engine, if you will) with the various interfaces built on top. Since there wasn't a lot of OS-specific functionality in the engine, it was decided to make it portable across all target platforms. Thus, anything built on top of the engine services API would be inherently portable.
The first design task was to create a fast/efficient difference generator that would produce minimal increments in storage space for typical sets of module differences. Since the types of storage media (random access or write once) affect which strategy is best for storing differences, the difference generator was built to produce both forward and backward differences. On random access storage, reverse differences lead to the quickest fetch times for tip modules. On write once media, forward differences yielded a significant reduction in module storage requirements, since a complete copy of the 1st version of the module is always written the first time around and can never be erased. Furthermore, for branching, it makes sense to run reverse differences from the main stem's tip to the branch point, at which point forward differences are run to the branch's tip. Thus, bidirectional difference capability was important.
The next design task was to produce an ultra-reliable storage mechanism with automatic recoverability. This mechanism also needed to be fast so that using it would not impact overall system performance. Once we had designed such a mechanism, we integrated the difference engine into it so that module differences could be stored. A method of history storage was added to save metadata (version information, etc.) thereby completing the basic version control functionality.
We implemented all of the basic version control functionality as a version control API. This basic functionality was provided on DOS, Windows and Unix platforms. Our goals of building a product that did fast check in/out, used disk space sparingly and would never, ever lose a version of a checked-in object (surprisingly, this critical requirement was not met by competing version control systems at the time) were admirably met.
Using the version control API, we built version control directly into several popular programmer's text editors as well as a platform-specific (Windows) GUI. These interfaces made it simple and easy for the ultimate consumer of version control (i.e. the programmer) to perform all of the common version control functions from a familiar place.
To facilitate remote development projects, whereby a number of developers at distributed locations could collaborate on a single piece of software, we implemented a series of remote version control operations that could be performed over the Internet to retrieve and replace working versions of checked-in objects. These operations were supported through a client program that submitted TCP requests to a version control service running on the central repository server.
Acceptance of the product in the user community was good and our strict adherence to the design criteria of speed and recoverability meant that the product received very favorable reviews. In addition, the client was able to offer a guarantee that no data would every be lost by the product or they would do whatever it took to recover it. No claim was ever made against this guarantee, a testament to the results achievable by BSM Development, given a rigorous set of product requirements.