SCM Meeting 2010-03-03

Agenda:

• Continue discussions on making the spec less file-centric

Minutes

Present: NickCrossley, RobinFuller, DaveJohnson, PeterHack, PaulKomar.

Nick first went over the changes made to the SCM resource definitions, with the first draft of making the SCM spec less file-centric by adding a generic object version supertype, and changing the membership links to return sets of resources of more arbitrary types.

On the question of whether the 'versioned object' type was an abstract type or a specific type, the group agreed that it could be an abstract type; all actual resources returned by an SCM provider would be of more specific subtypes, including provider-specific types not defined by OSLC.

We then went through the SCM open issues list. The group agreed that configurations and components could be subtypes of the generic object version type, and that no distinction was currently required between types that could or could not be containers. We also agreed that there appears to be no requirement for the SCM spec to define more than one containment relationship. The meaning of that relationship might vary according to the type of the container and the contained objects - for example, the meaning of a component in a configuration is slightly different from the meaning of a file in a directory. If required, providers may add multiple containment relationships (of different provider-defined relationship types).

As suggested in email by FrankSchophuizen, and pending any further thought by PeterHack, the group also agreed that OSLC need not distinguish between incremental and non-incremental baselines (as implemented in Rational ClearCase). Rather, OSLC SCM services will expose properties of the overall baseline regardless of whether that baseline was set up as a single object or as a series of incremental baselines.

Nick suggested that the default set of properties returned for a resource in the absence of any oslc:properties parameter be the set of properties defined for all OSLC resources in the core spec; Dave will consider that as an alternative to the approach taken in CM 1.0, where all properties were returned by default. The SCM group does not consider the CM 1.0 approach scalable. There should also be an easy way to get all properties.

Paul asked about the baseline compare operation. Nick wondered how common the results of such an operation was between the three main Rational SCM providers, and suggested we follow up on the mailing list. If the nature of the baseline comparison operation was very different between those provider, we might have to defer provision of this operation to a subsequent release of OSLC SCM.

There was some discussion about whether or not SCM providers should also be required to implement one of the REST reporting APIs. Such a requirement would not be in the scope of the SCM spec, and would probably not be implementable in the suggested SCM 1.0 timeframe anyway.