There are three basic paradigms used for source code control systems: braching, database-query, and change-sets.
Branching source control systems, as exemplified by CVS, use numbered revisions to files. The change history of a file or tree is stored in a set of branches that form a tree. The basic actions of a user are to check-out a brach, make changes, check it in, and maybe, merge one branch into another. Branching has several weaknesses: it requires a central server; as branches diverge, changes are compressed and thus hard to merge; and the relationship between the branches and the directory structure does not allow much dynamic reconfiguring.
Database-query source control systems, as exemplified by Atria's ClearCase, provide each developer with a view of the source tree that is the result of a database query. This provides an ability to switch views quickly. The cost of this is in complexity and in the difficulty of mapping the development process into the right access method. This chief problems with ClearCase are its cost and performance.
Although there is a source control system for sale that uses change-sets, there are no decent implementations of change-set style source control systems available. In a change-set system, there are lots of source trees. They get updated by incorporating changes from other trees. This is a merge process, but is almost always automatable. The advantage of a change-set system is that the semantics are very clean: do you want this change or not?
DMS is a change-set style source control system that is under development. The features that make DMS particularly interesting are the simplicity of the model; support for distributed develpment; the close binding of developement tasks to source control actions; the ability of the system to act as a distribution system; and the ability to pass changes between largely diverged development trees.
From the users' point-of-view there are just two kinds of tree: develpment trees and release trees. The only difference is that release trees are frozen. No tree is a parent or child to another. Trees are connected to each other by establishing links. Changes that are exported are visible to trees that have links to the tree that exported the changes. Changes that are visible may be incorporated. Changes that are incoroporated may be blessed or rejected. Rules may be established to automatically import and export changes.
Changes must be organized and annotated before they can be exported. With annatations, you can specifiy that this change is part of that development effort; or that these two changes are mutually exclusive; or that they are mutually dependent. This semantic information is critical for supporting good software engineering practices. No other source control model can support annotations.
Although there is a performance difference, there is no semantic difference between two trees on the same fileserver and two trees on different continents. The links between trees may use different communications mediums: both NFS and email are supported.
Since trees may be kept sychronized across wide-area networks, DMS can be used a source distribution mechinism. Since DMS will be given away to those who are working on free software, it is expect that DMS will become the primary method for maintaining private copies of public software.
What does this buy you? Here's an example: it involves two groups, four users and four trees. Groups A and B have divergent sources that at one time were the same or similar. Developer A1 of group A fixes a bug. The bug fix should apply to everyone who derrived from the original tree. A1 can export that bug to group A's tree, to group B's tree, and to developer B1 (in group B). Anywhere it's sent, if it is further exported it can eventually reach everyone.
The linked development trees form an ad-hoc network. The thing that DMS does that no other system does is allow changes to propgate at different speeds. Bug fixes can fly across the network while enhancements crawl.
DMS is an unfunded project. Development is slow and DMS is not expected to be ready until sometime in '98.
DMS is being written in perl5. Currently, a multi-user transaction database is being built because there do not appear to be any reliable, multiuser, free relational databases.