CcFile and CcDirectory proxy methods

A CcFile or CcDirectory resource represents a file or directory in an HCL VersionVault view (CcView). These resources are under source control or can be put under source control. CcFile and CcDirectory are VersionVault-specific extension of the API. CcFile extends the ControllableResource interface and CcDirectory extends the ControllableFolder interface. CcFile supports a number of methods such as:
  • doVersionControl(): Place a view-private file under version control.
  • doCheckout(): Check out a version-controlled file.
  • doCheckin(): Check in a checked-out file.
  • doLoad(): Load a file or directory tree from the VersionVault CM server into a local web view.
  • doRefresh(): Update the client resource from the server; potentially load a more recent element version into the web view.

The API distinguishes between a CcFile, which is the file in a view through which the above operations are performed, from the corresponding VersionVault element and version (CcElement and CcVersion).

The CcFile.doVersionControl() method creates a CcElement resource and an initial CcVersion resource that will have the same contents as the CcFile.

The following code fragment builds a CcFile proxy for a known file in a file area, and checks out that file. The IS_CHECKED_OUT property is checked before and after the checkout operation.
 // Get the VersionVault provider.
        CcProvider provider = ...;

        // Create a CcFile proxy for the file to be checked out.
        // First, create a plain old Java "File" instance from the file's path.
        // Then create an StpLocation instance from that file.
        // Finally, create a CcFile proxy from the location.
        File file = new File("C:/my_views/example_view/avob/example.txt");
        StpLocation fileLoc = provider.filePathLocation(Domain.CLEAR_CASE, file);
        CcFile testFile = provider.ccFile(fileLoc);

        // Create a property request for the file's properties that we're
        // interested in.  Read those properties.  Note that the resulting
        // property values are available *only* in the CcFile proxy returned by
        // doReadProperties(), not in the original proxy.
        PropertyRequest wantedProps = new PropertyRequest(
                CcFile.IS_VERSION_CONTROLLED,
                CcFile.IS_CHECKED_OUT);
        testFile = (CcFile) testFile.doReadProperties(wantedProps);

        if ( ! testFile.getIsVersionControlled()) {
            // The file is not yet under version control, so control it.
            // At the same time, re-read the properties we're interested in.
            testFile = (CcFile) testFile.doVersionControl(wantedProps);
        }

        if ( ! testFile.getIsCheckedOut()) {
            // The file is not yet checked out, so check it out.
            // At the same time, re-read the properties we're interested in.
            testFile = testFile.doCcCheckout(null, wantedProps);
        }

        // Verify that the file is now version controlled and checked out.
        assert(testFile.getIsVersionControlled());
        assert(testFile.getIsCheckedOut());

Certain operations on resources in a local web view may or may not interact with a server. For example:

  • Reading a file's content by calling the doReadContent() method may be satisfied locally if possible.
  • Operations such as adding a file to source control by calling the doVersionControl() method always require server interaction.
  • Operations such as readContent() or readProperties() are guaranteed not to interact with the server, but they may fail or produce incomplete results depending on the local state of the resource.

The Resource interface itself does not supply a method for creating the underlying resource, because some resources cannot be created by the user. Note the distinction between creating the proxy, which is a matter of instantiating a Resource object, and creating the resource, which must be done by calling the doCreateResource() or doCreateVersionControlledResource() method.