Repository

Most of the work and error checking occurs within the repository package. The repository is implemented by the {@link com.ibm.rational.wvcm.ri.repo.RiRepo} class, which represents an entire WVCM repository in-memory.

Each WVCM resource interface has a corresponding repository class, whose name starts with RiRepo and ends with the name of the interface, e.g. an instance of RiRepoBaseline represents a single persistent baseline. All repository resources extend RiRepoResource; the hierarchy of repository resources is identical to that of WVCM.

These repository objects are not proxies but instead are the actual resources to which the proxies refer. As such, the repository will only contain a single instance of a given repository object. An instance of a RiRepoResource may be referenced by 0, 1 or many client-side proxies.

Each RiRepoResource instance stores a HashMap of all its properties and corresponding values. Repository resources never use instance variables to store specific property values. Instead, each property is stored in a common way and accessed using common code. e.g. if the DISPLAY_NAME property value is requested, its property is looked up in the map and returned. Note that a few properties are never stored but instead are calculated at the moment their value is requested; this is simply easier to do in some cases than trying to constantly keep a property's value current.

Many resource property values reference other resources or lists of resources. The repository implements this by having such property values directly reference the other RiRepoResource instances. (An alternative may have been to store a location of the referenced repository resource and to then look it up later.)

e.g. A Workspace has a property named VERSION_HISTORY, which would of course be a VersionHistory resource. The repository represents these objects by having a single RiRepoWorkspace instance with a properties map. A lookup of the property VERSION_HISTORY within that map returns an instance of RiRepoVersionHistory. The RiRepoWorkspace instance is rooted off of a RiRepoFolder contained within the root of the RiRepo itself. All repository resource can ultimately be gotten to by starting at the RiRepo root and following the references through the properties to other RiRepoResource instances.

Note that PATHNAME_LOCATION of an RiRepoResource is computed, rather than stored in the properties map. This simplifies the implementation of the move/rename operations (doRebindChild), which otherwise would have to update the stored pathnames of all the affected resources.

Location string syntax supports a parent/child relationship between resources. This is reflected in the repository's implementation by having the CHILD_BINDING_LIST and PARENT_BINDING_LIST properties store lists of {@link com.ibm.rational.wvcm.ri.repo.RiRepoIFolder.RepoBinding} instances. A RepoBinding stores both the binding name and the RiRepoResource it binds to. This allows a given RiRepoResource instance to have more than one location to it via multiple bindings. A RepoBinding instance is persistent just like the RiRepoResource instances. e.g. if a RiRepoControllableFolder contains a RiRepoControllableResource, there will be a single RepoBinding instance between those two resources to tie them together. The CHILD_BINDING_LIST property of the parent RiRepoControllableFolder will contain that RepoBinding instance, and the PARENT_BINDING_LIST property of the RiRepoControllableResource will also contain that same RepoBinding instance. A rename is as simple as changing the Binding name of that Binding instance. Breaking a binding requires removal of that RepoBinding from both the parent's CHILD_BINDING_LIST and the child's PARENT_BINDING_LIST.