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

[Harshavardhana N Reddy]

After I read the Remark 7, I got the following questions:

Is it that the client can only do directory comparison between two 
versions of a directory:

        1. When the resource of each member in the directory is available? 
(true for both the versions of a directory considered for comparison)
        2. When the result obtained is 'oslc_scm.context' based and not 
'oslc_scm:member_names' based?

If yes, does each such member (along with its associated resource) becomes 
an object?

In which case it has unique S.C.M. properties:- 'dc:indentifier', 
'oslc_scm:fullName'. Is it possible to (re)use any one of these two 
properties of an object for its identification, as it is unique?

This is my first post in this mail listing, please correct me if I am 
wrong.

Thanks,
Harsha



From:
Frank Schophuizen <fschophuizen at gmail.com>
To:
oslc-scm at open-services.net
Date:
04/17/2010 11:15 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 5: Configuration
The text "top level objects" appears first here. It is not clear how top 
level objects differ from other objects. May be it intended to define that 
a configuration contains a single entrypoint which acts as a "handle" to 
the configuration.

Remark 6: Directory Version Properties
The description of oslc_scm:memberName suggests only files and 
directories. But in the definition of "Directory and file versions" it is 
stated that a directory may contain (sub)configurations. The property 
should be able to return those (sub)configuration names too.

Remark 7: Directory Version Properties
The memberName property may be too limited to identify the members of a 
directory version for comparison. For example if version 1 contains a 
member foo.c, versions 2 until 5 contain no member foo.c, and version 6 
contains a member foo.c, it is uncertain whether both foo.c members are 
versions of the same object or versions of different objects (which happen 
to have the same name).
In an SCM system, members of the same name may occur multiple times as 
long as they are contained in different directories (= different directory 
paths).
I propose to add a properties uniqueName to return a unique identifier in 
the repository namespace, to distinquish between equal memberName values. 
The layout of uniqueName is provider-specific, which means that 
uniqueNames cannot be compared/reused across providers but memberName can.

In addition, we have to add to the definition of memberName that a 
directory version does not contain multiple members with the same 
memberName.

And we must be clear whether the OSLCM_SCM spec permits case-insensitive 
names ("MakeFile" = "makefile") or case-sensitive names in memberName.

Remark 8: Symlinks
Add that service providers for systems that do not support symbolic links 
MAY use the Symlink resource. For example, ClearCase supports symlinks on 
Windows systems, although in the work area (on the Windows file system) 
the symlinks are translated into copies.

Remark 9: Symlinks
The current definition assumes that symlinks are "file system path". But I 
propose that a symlink can also be a URI (string) to an object.

Remark 10: Directory version
Remark 9 brings me back to the definition of a directory. A directory 
version should be capable of containing a symlink.

Remark 11: Symlinks
Add that a symlink is a specific type of object version. If not, then 
changing a symlink will update all prior baselines that contain the 
symlink.

== that's it for today ==

Feel free to comment on my remarks.

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/20100418/07682d62/attachment-0003.html>