[oslc-scm] Making OSLC SCM less file-centric

[Nick Crossley]

I have had a request to make the SCM services less file-centric.

This is fairly easy to do.  I would change the existing OSLC SCM spec to 
insert a more abstract VersionedObject resource into the data model, and 
make FileVersion and DirectoryVersion more specific instances of 
VersionedObject.  There is nothing specific to the baseline, 
configuration, component, or change set concepts that really makes them 
file-centric.

In other words, the resulting data model would be that a baseline is a 
frozen instance of a configuration, where a configuration is a set of one 
or more components.  A component is a collection of versioned objects.  At 
any given instant, a component identifies a specific set of objects and 
specific versions of those objects; however, the set of objects and the 
versions of those objects used in a (non-frozen) component can vary over 
time.  Versioned objects are of various types, and some of those types 
have 'containment' relationships to other objects.  The exact set of 
object types, and the available containment relationships, can vary 
between SCM providers.

I think most SCM systems have models like this: we simplified it to just 
file and directory types in the current spec partly because we have no 
current or proposed consumers asking for anything more!  In many cases, 
the underlying model is very general and extensible.

Does anyone have any objection to this?  If not, I'll go ahead and change 
the spec as described.

Meanwhile, please review the pages recently changed on the SCM pages on 
the wiki - particularly the resource definitions and the issues list 
(focus on the SCM-specific issues rather than those generic to OSLC as a 
whole - I'll address that list with the other workgroups).  I have also 
updated the proposed schedule to reflect where we are and to allow for us 
to base the SCM v1.0 spec on the forthcoming core spec.  Please let me 
know if the proposed schedule changes cause you any concern.

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-scm_open-services.net/attachments/20100222/9003556c/attachment-0003.html>