Dave Lewis writes:

I think you're probably referring to a tool called "Aide De Campe" (ADC) which is called "TrueSoft" these days. It is changeset (cset) based, not line-based. A Line-based tool would let you checkin/checkout at the granularity of lines and statements rather than files & directories. The "Delta System" used by Bell Labs/Lucent since about 1987 is such a system (a paper on the Delta System was given at the SCM8 conference this year).

A cset-based, or "logical" change-based system associates all lines of all files that were modified with the same "delta". In this case, instead of being called a "delta" its called a changeset or cset - the set of lines that were changed for all files on behalf of the same task, feature, or fix). With ADC, there is no such thing as revisions of files, only of csets (logical changes), and perhaps of the portion of a cset associated with a given file.

Furthermore, you can compose change-sets and change-lists (clists are lists of csets) algebraically using addition and subtraction to your hearts content. In theory, there is never any merging of conflicting changes, there is only composition, since each line is unique to a single cset. In practice however, just because the algorithm has no trouble figuring out which line to accept doesn't mean the result won't have conflicting results that will fail to function, or even build, correctly. And even if it does, the resulting configuration still needs to be built and verified/validated.

Some file-based systems offer change *packages* (often billing them as change-sets, even though they aren't according to ADC's definition of the term). A change-package is the set of file revisions participating in a single logical change-task. (Note it is the entire revisions, not just the changes). A change-package groups those revisions into a single named entity, but still provides access to the individual parts. A cset is atomic however (you can't ask for part of a cset without getting all of it). A change-package may also throw together other information as part of the "package", like context info about the change task (similar to a p4 "job").

Think of the difference between file-based SCM and change-based SCM as the difference between a *physical* configuration (parts/assemblies of components and component revisions) versus a *functional* configuration (parts/assemblies of features and fixes).

There is a debate that comes up almost regularly in SCM forums about the benefits of change-based versus file-based SCM, and each has their own zealous advocates who swear by one and scoff at the other.

Me personally, I liken it to the old physics debate of whether an electron is a particle or a wave. In fact, it can be both, depending on the means used to observe and measure it. I think SCM is the same way. Sometimes we need to see change as a "wave", consisting of all physical modifications for the same logical, coherent purpose (regardless of how many files we had to touch). Sometimes we need to see change as a particle, tracking, or even backing out, a particular delta for a particular revision of a particular file.

IMHO the underlying SCM tool will have to choose a single, underlying physical implementation, but should be able to provide the user both views (the implementation chosen will affect storage/speed aspects for the other "view"). One of the reasons I like Perforce is that it does a very respectable job of this with its "jobs" and "change-lists", all for a nice price with good performance and functionality.

For more info on change-sets and change-packages, go to the "SCM" links of my ACME page at http://www.enteract.com/~bradapp/acme/. Of particular interest is the paper by Darcy Weber (of Continuus) presented at the SCM7 conference which compares and contrasts csets versus cpkgs (or ctasks).

If anyone has any additional info on the history of csets and cpkgs, I would be very interested in hearing it (sens me private email if you like). I'm particularly interested in how they (or their predecessors) were implemented in early SCM tools (like change-packets in the CMS/MMS toolset for VMS, and other systems).

Cheers!

--- Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/ "And miles to go before I sleep." | 3700+ WWW links on CS & Sw-Eng