Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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.

 

  1. 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.

 

  1. 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.

 

  1. 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.

 

  1. 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.

 

  1. CreateStream: For completeness, we should have a ModifyStream and RemoveStream.

 

  1. 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.

 

  1. 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
     

Back to the top