Architecture
* This was a client-server based system, with command-line and graphical clients for several platforms and servers available for several flavors of Unix. * A relational database was used to keep tracking information but a separate Source Control Manager such asConcepts
* Files are created and associated with Components. * Components form a directed graph where each Component can have several parents. Components are a logical grouping mechanism allowing Files to be grouped together without regard to their physical pathnames (unlike directories or folders which lie on the path). * Permissions can be given at the Component level, allowing for distributed administration. The permission to give other permissions can be granted. * A Release was a set of files with a common root. Releases could share files with other releases. The sharing could be defined to follow the latest version (sometimes called "tip") or a specific version within the release. This was called "linking". * A Level is a snapshot of all files. Similar to a "tag" in other source control systems - but with a twist. If the Release is in "binding mode" (most commonly used), the Levels contain only the files referenced by the LevelMembers (Defects and Features). As a result, a Level only contains changes (file versions) that are approved and not just the latest file versions in the repository.Features
* Defect tracking was integrated into the source control system. * Ability to configure a repository to require defects to be associated with every file check-in. * Levels are used to manage sets of defects, allowing managers to think in terms of sets of changes rather than sets of files. * Distributed administration allows for delegation of authority. This is particularly useful in large teams. * It has the ability to track file histories even after renaming. This is because the filename on disk was a number and the filename in the database could be changed. * Files could be shared between source code ReleasesWeaknesses
* Locking used to be the only mechanism for controlling access to files. This was typical for source control systems of that time period but would be considered a major weakness today. The most current implementation has become more robust, allowing concurrent development, conflict resolution and merge. * Having a centralized server limits the ability to work in disconnected manner. Although, this is a failing of nearly all remote source control systems unless a local repository is created, giving the illusion of redundancy and source control, which will ultimately require a sync with the remote source control server at some point to submit any deltas.History
It was sold and distributed through the mid-late 1990s by the International Business Machines Corporation (IBM) and was derived in part from software purchased from HP and from IBM's internal-use-only system, IDSS. In the 1990s, this system was used to manage the IBM OS/2 andReferences
* * * * {{Version control software Proprietary version control systems Configuration Management Version Control Discontinued version control systems