[oslc-scm] SCM 1.0 spec updated to follow core spec draft - ready for convergence?

[Jean-Michel Lemieux]

Thanks Frank and Nick,

- I agree with the comment about change sets and being in a single stream. 
That is too limiting and not required in this level of spec. I suggest we 
make this an optional property and allow providers to return one or many.

- The above applies to baselines as well. 

- I'm trying to figure out how to navigate from a change set to it's 
comment. The examples have oslc_scm:comment property but I can't find that 
on the object version.

Cheers,
Jean-Michel



From:   Frank Schophuizen <fschophuizen at gmail.com>
To:     oslc-scm at open-services.net
Date:   2010/04/16 02:10 AM
Subject:        Re: [oslc-scm] SCM 1.0 spec updated to follow core spec 
draft - ready for convergence?
Sent by:        oslc-scm-bounces at open-services.net



Remark 1: definition of baseline
Replace "in some providers, a baseline can be an incremental baseline" 
should be replaced by "in some providers, a baseline can be implemented an 
incremental baseline". Although the definition states clearly that a 
baseline is "A frozen configuration", the statement "can be an incremental 
baseline" might be misleading to suggest that a baseline may be a 
"partial" configuration.

Remark 2: definition of component
The definition does not define unambiguously that a component may be a set 
from multiple configurations or a set from a single configuration. When 
the object versions are selected by criteria such as property values, the 
result may be from multiple configurations (unless we consider the entire 
repository as a configuration too).

Remark 3: Change set
A change set should be indivisible. But there are providers (e.g. 
ClearCase/UCM) that create a single change set to contain the merge 
between two streams. This is not an indivisible change, since the changes 
originate from many other change sets.
In the definition, it is not stated that a change set MUST be indivisible, 
but the description does suggest it. Add a sentence that a change set may 
be a merge of other change sets and thus associates to the collective set 
of object versions of the original change sets.

Remark 4: Change set
I am not sure that a change set should be associated to a single stream. 
One logical change may consist of the collective contribution of several 
streams, especially for software interface modifications or refactoring. 
Shouldn't we leave the option open to allow changes from multiple streams 
in a single change set, and leave it up to the provider to limit the 
number of streams to one?

More over, if a change set identifies the changes applied to a stream, 
then apply the changes to another stream would require multiple streams to 
be associated with the change set.

== more remarks may follow later ==

Frank.

-- 
TOPIC Embedded Systems
P.O. box 440, NL-5680 AK Best
Netherlands
Phone (+31) 499 336979
Fax   (+31) 499 336970_______________________________________________
Oslc-Scm mailing list
Oslc-Scm at open-services.net
http://open-services.net/mailman/listinfo/oslc-scm_open-services.net

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