Thanks Adam
Other things we need are:
1. an ALF specific parameter. This should hold
various IDs that should be returned by the tool on any event that it raises as a
result of the call. This is used to set the "previousEvent" field in the
event structure and to provide an id for Correlation to facilitate
callback. I don't think there is a suitable ID currently although event ID
could be part of it. We should to discuss possible formats for this
structure. It will probably be common to all ALF vocabularies. The
Base ALF event structure is probably a good place to
start.
2. return values - really response messages. Most
operations will provide a synchronous response of some kind even if they later
raise an event.
3. faults - we need to define a common format for
vocabulary specific faults and come up with a set of faults for the SCM
vocabulary.
Tim
First off, apologies for not being
that active on the ALF lists lately – I’ve been busy getting AccuRev version 4.5
out.
I was looking over the API defined
in http://wiki.eclipse.org/index.php/ALF/SCM_Vocabulary
(the Java pseudocode in section 5) from the point of view of whether it is a
complete/consistent/usable SCM API. Generally it seems to be taking shape
nicely. Here are some details-level comments. I can go in and correct these
myself, but I wanted to get consensus from the larger group
first.
- CreateWorkspace/ModifyWorkspace/RemoveWorkspace:
For completeness, also need a ShowWorkspaces. Similar comment applies to many
of the other Create* methods. Also, for consistency with the other API’s that
take a workspace as input, ModifyWorkspace should take a “Workspace workspace”
argument rather than a “String workspaceName”
argument.
- AddAssets/RemoveAssets: For
completeness, should have a ListAssets which would list assets (elements)
under version control. It should take a Workspace or Stream as input, and
produce a directory listing of the elements that are under version control in
that workspace or stream.
- RemoveAssets should
probably take a Workspace rather than a Stream, on the theory that
asset-changing operations (e.g. add/create-new-version/remove) all should be
done through a workspace. The general model should be that you do work in
workspaces, and changes only get into streams by
promoting.
- IntentToModify
(“checkout”) should have an inverse operation (“uncheckout”), for the use case
where you check out something but then change your mind. Let’s see, should we
call it the NeverMind() method? J Also, I
think this is implied, but we should say explicitly that CreateNewVersions
(“checkin”) releases the checkout for the specified
elements.
- CreateStream: For
completeness, we should have a ModifyStream and
RemoveStream.
- CreateBaseline: This
should take an optional Workspace argument also. We should allow the caller to
specify either (a) Just a workspace (baseline is current contents of the
workspace), (b) Stream (baseline is latest versions in the given stream, or
(c) Configuration (the result of applying the given Configuration rules). Only
one of these 3 should be specified, or else the baseline is
over-specified.
- UpdateWorkset: Should
be UpdateWorkspace. Also, should make clear that “baseline”, “stream”, and
“configuration” arguments are all optional and the normal case is to update
the workspace from its already-defined configuration,
e.g.
UpdateWorkspace( Repository repository, // Workspace workspace, // Baseline baseline, // (optional) if fetching versions from an existing baseline Stream stream, // (optional) to fetch latest versions in the given stream/branch Configuration configuration, // (optional) overrides workspace’s config-spec to specify what versions to fetch Options options, // standard options such as refresh, replace, etc. OtherOptions otherOptions // tool specific options ) 8. Need an API to create/modify/remove Components. 9. Need to (somehow) deal with user-id’s, authentication (a “Login” method), and ownership of assets (pass explicit user-id’s, or get implicitly from logged-in user at time of Create* operation?). That’s it. If people agree generally, I can volunteer to update section 5 of the SCM Vocabulary document in the Wiki. Richard Title AccuRev
**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
|