[oslc-plm] Versioning, branching, configurations, baselines, streams, work flow process
david.honey at uk.ibm.com
Wed Sep 14 07:29:54 EDT 2011
Dear OSLC PLM workgroup member,
As promised in the OSLC PLM workgroup meeting (2011-09-13), I have
described below some concepts relating to versioning, branching,
configurations and baselines and streams as seen across a range of SCM
tools. The intent of this is to:
Act as a catalyst for the workgroup meeting next week (2011-09-20).
Help establish which of these concepts exist in the PLM world.
Determine if different terminology is used.
Determine the versioning requirement concepts needed to support the use
cases for the PLM reference model.
The challenge in getting such concepts into the OSLC core spec is to find
the right balance between conflicting issues:
The abstraction needs to be flexible enough that it can be supported by
It needs to be specific enough to allow OSLC consumers and providers to
understand the semantics and derive value from it.
In the SCM world, the terms version and revision commonly mean the same
thing. There are two versioning models commonly in use:
The versioned object model. Each CI (configuration item) such as a file
can undergo changes that result in new versions. Each such object version
has a specific identity, often using the version or revision id as part of
that UUID. Most SCM tools use this model: SCCS, RCS, CVS, CMS, PVCS,
Clearcase, Synergy to name a few. This is the most common versioning
The versioned repository model. The tool provides a versioned repository
and each change committed to that repository results in a new version or
revision of the repository. Files and directories are not individually
versioned. A question such as "Who made the change in version 5 of file
F?" are meaningless. Instead, one asks "What owner does file F have in
version 5 of the repository?". Subversion is the best example of this
model. It also means that you can have the same file version in many
different versions of the repository.
Reconciling these two models is awkward. One can partly map #2 into #1 by
representing the history as the repository versions for each changed CI.
For example, a file might have a history such as: 234 --> 467 --> 1234.
The first version was created in repository revision 234. The next change
was in repository revision 467. The last change was in repository revision
1234. However, there can be other significant complexities.
There are two locking models commonly used in SCM tools:
Locking at check out - In this model, when a user wants to make a change,
they typically create a lock on the leaf version to prevent another user
from attempting to make a parallel change. Some tools support both
exclusive locks and shared locks. A new version of the object is not
created until the user commits a change to the system. That commit
releases any lock on the object that was checked out. This is the most
New version created at check out. There is no locking as such. When a user
wants to make a change, they check out the file, and that creates a new
version that is modifiable by the user. If parallel versions are to be
restricted, the restriction is applied at check out and/or check in. This
model is used by Rational Synergy.
Some tools such as Subversion effectively allow one or many users to
create a local workspace that has a copy of the original files. Those
copies are not recorded in the repository. Users can delete these
workspaces without needing any access to the tool repository.
While the locking model itself is probably not of interest to the OSLC
core group, it may be relevant in terms of when OSLC resources are known
and how OSLC consumers can find out who has checked out a particular file.
Branching and parallel development
SCM tools have various concepts around branching and parallel development.
Commonly used models here are:
Branch as an explicit entity. Some tools require that in order to create a
parallel version, this must be done on a branch. The branch is created as
a separate resource, either explicitly, or implicitly as part of the
parallel check out. Rational Clearcase is an example of this type.
Implied branching. In this model, parallel versions may be checked out and
are associated with some context. That context is often related to a
release or a stream. In this model, if a change is required for a variant,
this does not require a specific branch. The object version's associated
context (such as a release, task, stream etc) determines that the change
only gets included in a specific variant or release. Rational Synergy and
Rational RTC are examples of tools that follow this model.
No branching. In this model, there is no concept of a branch at all. The
effect of branching may be simulated by copying data to a different area
of the same version repository, or a different repository. Subversion is a
modern tool using this model.
If an SCM tool supports a configuration it usually means a versioned
container. That container records the structure of its members and which
versions of those members are used in the configuration. Support for this
No configurations. Some tools only version files and do not version
structures. Tools such as SCCS, RCS and CMS provided no means to version
A tool using the versioned repository model simply treats a configuration
as a directory somewhere in the respository at some respository revision
level. Subversion is a good example of this.
Explicit configurations. These are explicit versioned objects in the
repository, and can be checked out, updated, compared and so on. Rational
Synergy is an example of this type.
In the SCM world, the term baseline usually means an immutable record of a
collection of files. The details vary between SCM tools, and some tools
may not have an explicit representation. Examples include:
Tools that only support tagging. Tools of this type allow the user to use
some user-defined string tag to one or a collection of objects. An object
may have multiple tags. SCCS, RCS and CVS are examples.
Tools that implicitly support baselining. Subversion is an example. It
does not directly support baselining. Common practice is to copy a set of
directories and files to a separate location within the repository, and in
doing so, a new version of the whole repository is created. However, the
user can make additional changes. The state of the repository immediately
after the copy represents an immutable snapshot. However, those files can
still be changed, and if so, that creates later revisions of the
Tools that explicitly support baselines. When a baseline is created, it is
represented as an explicit entity with its own meta-data. Rational Synergy
is a good example.
Tools that support parallel development for different releases or
variants, usually provide some means of defining a stream or a release.
This allows the changes made by developers to target one or many
deliverable releases or variants. The details tend to vary a lot between
tools. Some examples include:
Streams by tagging. Early version control tools relied on the user
appropriately tagging the new versions they created.
Explicit streams. Rational RTC is an example of this. Users work in a
project area associated with a stream. Not all tools of this type make it
easy to share changes across streams, or selectively merge parallel
Explicit releases. This is very similar to explicit streams. In Rational
Synergy, make changes against a task that is associated with a release
value. That task may also be included in other releases according to
process rules set up by a build manager.
Work flow process
Most modern SCM tools support a flexible and configurable work flow
process. This process controls:
When users see changes from other developers.
What changes are collected for integration test builds and testing.
What changes are collected for system test builds and testing.
Inherent in this are the concepts of insulation and sharing. Insulation
means that a work area (sometimes called a staging area) is not changed
until the owner or manager of that work area decides they want changes.
For example, developers may not want to see later versions from other
developers until they have been checked in, and perhaps undergone some
level of testing. However, at some time, it is usually required that those
changes are shared with the team so that testing can use those changes,
and shared with build managers so those changes get included in official
builds and final deliverables.
The details of how tools support this varies widely:
In Rational Clearcase, config specs define the criteria for which version
should appear in a view (work area). This supports both a push model that
allows changes to be pushed to other work areas (sometimes suitable for
RAD), and a pull model in which the owner has control over when that work
area is updated.
In Rational Synergy, users decide when to perform an update members
operation and this selects the appropriate versions according to process
rules, and any corresponding work areas are updated.
In Rational RTC, users can choose which change sets to accept in the work
area associated with a project (and stream). Users see the list of pending
changes waiting to be either accepted into that work area, or delivered
from that work area.
Change sets or task-based CM
Early SCM versioning tools simply versioned individual files. The only
means of indicating that, say, 3 files were changed for a common purpose
might be to either use some form of tagging, or they used a separate tool
to describe a task or change request and entered that data at the time of
check in. More modern tools support the concept of a change set or task
that is a grouping of all of the changed files and directories for a
single logical purpose. Again, the details vary between tools:
Rational RTC uses change sets. All the changes delivered in a single
deliver are associated with a change set. A change set may optionally be
associated with a work item.
Rational Synergy uses tasks. Developers must explicitly create a task, and
all changes must be associated with a task. The completion of the task
automatically checks in its associated objects. Work flow process is based
Subversion treats a single commit of changes from work area to the
repository as a single change that results in a new revision of the
repository. In this way, all the changes made are implicitly linked by
sharing the same repository revision.
UUIDs - Universally unique identifiers
Most but not all SCM tools have some property or sets of properties that
form a UUID. SCM tools users tend not to be too concerned with UUIDs
unless they want to create links from other tools to a specific version of
a file or directory. However, from an OSLC provider viewpoint, the
convention would be that dcterms:identifier would be such a UUID. Such a
UUID might be constructed:
>From an archive file plus archive revision. For example, if you have a
path for an SCCS or RCS archive file, and know the revision, you have
uniquely identified the object.
>From a property that the repository created automatically. Examples here
include Rational RTC and Rational Synergy.
Unfortunately not all tools make it easy to support UUIDs, In Subversion,
the only UUID is one for the entire repository. If you access the
repository with a specific path and a repository revision, that does
unique identify a specific object version. However, there is a problem
with aliasing. Users can copy the object to many different locations, and
in effect this copies a link to the same object. Thus the same object
version may be accessible over many different paths and repository
revisions. Hence you might have different UUIDs that are aliases of an
Why is aliasing a problem?
One of the newest OSLC areas is the TRS (Tracked Resource Set). This
requires that an OSLC provider must be able to keep a change log that a
TRS consumer can use to determine which cached resources need to be
updated to reflect in near-real-time changes made since the data was
cached. The problem is that a change made via an alias needs to be
reflected in all the URIs for the same object version. Some tools may have
problems conforming to the OSLC TRS specification because they do not have
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oslc-Plm