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

[Frank Schophuizen]

*Remark 8: Change sets*
In the definition of change set, it is said to be "all or nothing". But how
about objects (VersionedObjects) that are associated with multiple change
sets?
For example:
Change set 123: directory dir1, version 10 is updated to add file foo.c
version 1, and many more other changes
Change set 125: directory dir1, version 10 is updated to add file bar.c
version 1, and many more other changes
Change set 126: merge of change set 123 and 125 to add both foo.c and bar.c
in directory dir1, version 12.

If foo.c and bar.c are not in cs126, then a configuration containing cs126
but not cs123 and cs125 will be inconsistent: dir1 contains foo.c and bar.c
but the configuration does not contain foo.c and bar.c
So, cs126 should contain foo.c and bar.c.

But a cs is completely included or completely excluded. Since foo.c is part
of cs123, all changes of cs123 should be included when cs126 is included.
Similarly cs125 should be included by cs126.
This way, the whole plate of spaghetti may be pulled in by a single change
set.
In other words, we must be careful with statements like "all or nothing". I
don't say that I disagree, only that we should be careful with it. We should
probably take a special look at "overlapping" change sets and how to deal
with them.

*Remark 9: Change sets*
We should also be careful with a term like "one logical change". Something
may be one logical change from one perspective, but not from another
perspective. For example, in SVN a submit transfers all changes made to the
workspace to the repository. This is "one logical change" as it is one
submit. However, the changes may be completely unrelated "logically" from a
product technical perspective. Several unrelated problems (solutions) and
implementations may be included.
So I propose to stick to the phrase that a change set is set a versions of
VersionedObjects that should not be separated.

*Remark 10: olcs_scm:changes*
A change set is an identifiable set of versions. Therefore, 2 properties
must be *required*: name and changes. The set of changes may be empty, but
it should always be possible to request set set of versions.

*Remark 11: get change set*
Don't we need a set operation for a change set? Probably the property
oslc_scm:changes is set as an indirect effect of another operation (e.g.
check in, or submit). But other properties (e.g. owner) should be
changeable.
And we should be explicit about changing the name (dc:identifier) of a
change set. I think we should forbid changing the dc:identifier property.

If we allow changing the change set (oslc_scm:changes), we should either
only support additions of changes. Or, if we allow dissociation of changes,
we should asure that all change are associated with at least one change set.

Frank.

-- 
TOPIC Embedded Systems
P.O. box 440, NL-5680 AK Best
Netherlands
Phone (+31) 499 336979
Fax   (+31) 499 336970
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-scm_open-services.net/attachments/20100223/211d17d0/attachment-0003.html>