This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
ScmHome
>
ScmMeetings
>
ScmMeeting20100303
(10 Mar 2010,
NickCrossley
)
(raw view)
---+ SCM Meeting 2010-03-03 *Agenda*: * Continue discussions on making the spec less file-centric *Minutes* Present: NickCrossley, [[RobinF][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.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r1 - 10 Mar 2010 - 13:35:13 -
NickCrossley
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback