IBM Configuration Management Version Control (CMVC)

• 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 as Source Code Control System (SCCS) or PVCS was used to maintain version history for each file. The filenames for these files are actually stored in the relational database - as a result, filenames in the SCCS tree are numeric ids.

• 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.

• 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 Releases

• 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.

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 and IBM AIX source code repositories.

CMVC sales and support terminated some time after IBM acquired Rational Software, its functions being superseded by products in the Rational product line (Rational ClearCase and Rational ClearQuest). However, some customer installations of CMVC remain in use as of 2008.[1]