Text: Version Models for Software Configuration Management, by Conradi and Westfechtel (ACM Computing Surveys, vol 30, no 2, June 1998, pp 232--282.
From Conradi and Wetfechtel: "Software Configuration Management (SCM) is the discipline of managing the evolution of large and complex software systems [Tichy 1988]."
discipline : "Controlled behavior", "A set of rules or methods", "A branch of knowledge" (from dictionary.com)
managing: "To direct or control the use of", "To succeed in accomplishing or achieving" (also from dictionary.com).
evolution: "A gradual process in which something changes into a different and usually more complex or better form", "A movement that is part of a set of ordered movements". (also from...)
large: "Of greater than average size, extent, quantity, or amount", "Of greater than average scope, breadth, or capacity". (also...)
complex: "Involved or intricate, as in structure; complicated" (also...)
What can we put together?
"Controlling our behavior to succeed in achieving changes to an important software system that are beneficial and typically result in a more complex system."
In the CMM model, SCM is a fundamental capability of every organization that is higher than level 1 ("initial").
Typically, we talk about SCM not just for knowledge and practice but in order to understand how to support it with technology.
SCM can be viewed as a management support discipline, helping managers control changes to products, or as a development support discipline, assisting developers in performing coordinated changes to products. Different SCM tools support these different goals.
A software product is the result of composing many objects.
A software product is not necessarily unique: it may have several or many instantiations in a product space. Sometimes the phrase product line captures this or a similar notion.
E.g., MS Word 2000 for Windows, MS Word 2000 for MacOS are instantiations of the same product.
Each instantiation composes (at least some) different objects.
Generally, objects are things we can manipulate independently. Practically speaking, for us this means files.
Q: What does it mean for a software product to be "composed" of a requirements object (among others)?
But, most objects are also structured internally. Thus, it may be useful to consider coarse-grained issues and fine-grained issues.
Might be useful to consider composite objects -- objects composed of other objects, but that are not "products".
Then, the software product is the root of a composition hierarchy.
The leaves of the hierarchy are atomic objects.
Might have more than just composition relationships -- might have dependency relationshsips between objects.
Build dependencies introduce a distinction between source and derived objects
VERY IMPORTANT: a complete build dependency specification would include the exact tools that are used to effect the operation.
The tool make only captures build dependencies.
Text: "A version (v) represents a state of an evolving item (i)".
Text uses item in section 3 rather than object
In section 2, in some cases, object == item; in other cases, object == version.
Q: Is a product an item or a version?
Items must have an identification mechanism (e.g., file name). Versions must refer to items, but also have their own identification mechanism (e.g., version numbers).
Versions of an item share invariants (common properties), e.g.:
Versions also differ between each other: this is called a delta
Extensional versioning simply means explicitly enumerating the versions of an item, and using them explicitly.
This is what we do all the time. Typically, each version has an explicit version id (a number), and optionally we might assign symbolic names to certain important versions.
Intensional versioning simply means implicitly maintaining versions, and using them implicitly by means of predicates.
Versions must have attributes with specific values, such that predicates can be evaluated over the the attributes.
Think of each version as a fact in a Prolog program, and a specific composition as an answer to a query over the facts and some rules.
Version: a specific occurrence of an item
Revision: a successor version (in time) to a predecessor version that is intended to supercede it.
Variant: An alternative version intended to coexist (in time) with other versions.
Fusion: A revision that combines predecessor variants. (I made this term up).
All of the last three are categories of versions.
Versions of an item are generally mutually exclusive in space with other versions.
Huh? Multiple versions of an item do not generally coexist in a single software product.
Q: What useful violations to this rule are there?
Version graph: versions are nodes, directed edges are immediate relations
Consider two relations: successor for revisions, offspring for variants.
A branch is a sequence of revisions
Text: "Variants can be represented by branches as long as their number is small."
If too many, clusters, N-dimensional tables, etc.
Alternative idea from state-based versioning (revisions, variants)
A version is some baseline item altered by applying some set of changes to it.
Each change is uniquely identified, and hopefully corresponds to some change request
Thus, each version is described by the change requests it implements.
E.g., "Give me the security patch plus the y2k patch but not the long-customer-id patch"
Text defines change-based extensional versioning as "mapping changes to state-based versions" (as far as I can tell).
Text defines change-based intensional versioning as "freely combining changes to construct new versions as required". This corresponds to each change being a boolean attribute (included or not). (this seems weak to me.)
The above def of intensional change-based versioning is called change sets.
OR node: a versioned object; only one edge is taken from an OR node
AND node: a version; all edges are taken from an AND node
Text: "A relationship is bound to a specific version if the corresponding AND edge ends at an AND node". I take this to mean transitively.
Product first: product is composed of objects, which are versioned
Version first: product has versions which are composed of versions of objects
Intertwined: product has versions which are composed of objects which are versioned
Q: Are the differences important?
Depends on which operations should be efficient. Also depends on what the "best" model is to present to the user. Class vote time!
As earlier, predicate-based selection of versions (configuration)
Predicate is over attributes: properties specified about the versioned objects, and that have specific values for each version.
Think of predicate as a query on a fact base. Some properties are constrained by the predicate, some are "don't care" terms.
Potentially many solutions (configurations) that satisfy the predicate.
State-based versioning: With M modules of V versions, V^M (V raised to M) potential configurations.
Change-based versioning: With C changes on a baseline, 2^C (2 raised to C) potential configurations.
Problem: many combinations may not be valid. Thus, add rules and constraints.
Problem: changes can depend on earlier changes. Thus, add dependencies (and maybe mutual exclusion).
Problem: Has this configuration ever been tested? Has this version ever been tested? (in a similar environment?)
Text: "confidentiality"??
Versioning your code and documents is obvious, but what else?
Version your configurations? Relationships between versions?
Version your configuration rules/constraints? (intensional versioning)
Version your tools!
Version your version system
Version your OS.
Version your hardware
Version your employees