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
