Agreed. Except for the first sentence
which should say “Richard”. J
From:
alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Buss
Sent: Monday, October 09, 2006
12:30 PM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] rounding
out the API in the SCM Vocabulary wiki
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
From:
alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Title
Sent: Monday, October 09, 2006
9:12 AM
To: alf-dev@xxxxxxxxxxx
Subject: [alf-dev] rounding out
the API in the SCM Vocabulary wiki
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.