[oslc-plm] Versioning, branching, configurations, baselines, streams, work flow process

[David Honey]

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 
most tools.
It needs to be specific enough to allow OSLC consumers and providers to 
understand the semantics and derive value from it.

Regards,
David.

-------------------------------------------------------------------------

Version, Revision
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 
model.
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.

Locking models
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 
common model.
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.

Configurations
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 
varies widely:
No configurations. Some tools only version files and do not version 
structures. Tools such as SCCS, RCS and CMS provided no means to version 
control structure.
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.

Baselines
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 
repository.
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.

Streams
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 
streams.
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 
on tasks.
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 
original UUID. 

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 
explicit UUIDs.






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-plm_open-services.net/attachments/20110914/ad4e7448/attachment-0003.html>