Complex projects of any kind involve the cooperation of large numbers of individuals and groups working on even larger numbers of interdependent items. In a particular, the development of application programs, operating systems, and other computer software commonly involves hundreds or thousands of people and documents numbering several orders of magnitude higher, over time periods of months and years.
A major part of managing large projects concerns systems for controlling different versions of versioned items documents and files. In program development, a source-code control system typically includes several pieces, almost always including a storage that provides efficient versioned storage of files, a differencing/merging engine for combining different versions of the same file, modules for operating upon multiple file formats such as text and graphics documents, and user interfaces for various parts of the system, including those for differencing and merging.
To integrate heterogeneous control systems into a useful development tool requires an architecture for integrating the many individual parts with a high degree of concinnity. The organizing force of a software architecture resides in the interfaces among the parts of the overall system. Interfaces are commonly implemented as application program interfaces (APIs). Traditional integration efforts coped with the depth and diversity of available source-control systems by defining a high-level API that abstracts both storage operations and user interfaces. For example, Microsoft Corp. integrated these functions into its own development tools using an interface called MSSCCI (Microsoft Source Code Control Interface). This interface proved inflexible, provided a limited model of the underlying data, and was unable to solve a broad range of important problems. This interface cannot mix pieces from different providers for performing other functions, or for performing existing functions in a different manner. Its design was not future-proof.
Another problem with traditional integration APIs is that they are based upon server namespaces. That is, an object is referred to by its path name and file name on the server that stores the files under development. This makes it hard to rename files. The API cannot determine that a reference to a file called ‘New’ refers to the same file that had been called ‘Old’. This was a problem even when all that was stored was source code, and traditional systems often disallowed name changes altogether. However, newer systems based on the World Wide Web require the names of objects to change often.
Existing development APIs have also been limited in their support for different kinds of files. They abstract the calculation of differences and merges as part of the storage. The types of files understood were bound into the products, and could not be extended by third parties so as to create new file formats. This problem becomes more important as Web-based systems grow in popularity. The Web employs many types of files, and no single system can address all of these formats, now or in the future. For Web-style projects, namespaces are a primary element of the software system. Moreover, traditional integration APIs provide no semantic support for parallel development. Users must manage their own copies of different versions of their projects.
The MSSCCI architecture mentioned above is widely supported in the software-development industry despite the fact that it remains a private interface without any formal standard. This and other available interfaces only support a small portion of the typical source-code control functions. They are not extensible to additional functions or formats, and they cannot be combined in mix-and-match combinations. Other current efforts address APIs and protocols for communicating with “version stores”—mechanisms for holding multiple versions of documents and files. None of the conventional systems provide a deep or consistent way for substituting third-party differencing and merging technologies into the versioned environment. This lack of any extensible architecture has hindered the development of versioning, especially for document management, where file formats are diverse and numerous, and where designers seldom work together with the organizations that produce version stores. Although some existing systems provide core support for object-based (rather than namespace-based) storage, they do not expose this capability deeply within their organization, if they have any extensibility at all.