Back to Archived Releases

 
VCM 2.0 Story
by Kevin McGuire 

The intention of this document is to describe the overall direction that VCM (Version Configuration Management) is taking in Eclipse, targeted at our 2.0 release. It provides a first look into the overall design goals and strategy we are taking, and includes a first cut of an important interface. The goal is to initiate discussion in the open source community, and to garner feedback from repository vendors looking to integrate with Eclipse.

Goals

The goal of the VCM support in the Eclipse Project is to provide a mechanism by which repository vendors can plug in adapters to integrate the full, rich, functionality of their repository solution into the Eclipse workbench in a first class way. The problem with many IDE integration approaches today is that they provide only a simple and generic level of support that we feel is an unacceptable level of integration. It does not allow repository vendors to showcase the unique benefits of their offering and treats repository/IDE integration as a second class afterthought. By contrast, we believe it is critically important that the vendor be able to integrate their product's workflow model into the overall Eclipse user experience. Our success will be measured by the number of repositories that we can support, by the richness of this support, and by the degree of VCM integration afforded to third party plugins.

Eclipse VCM 1.0

While we felt we achieved reasonable CVS support in 1.0, through that process we understood the places where our model would not translate well to other repository types. Thus it was a difficult but an absolutely necessary decision to hold it back from API status in 1.0. The architecture for 2.0 is significantly different than that in 1.0. For one, the API is smaller. Second, and most importantly, the workflow in VCM 1.0 was specific to Eclipse and difficult to customize for a given repository. This led to numerous fundamental problems in compatibility between the abstract Eclipse VCM model and repositories with rich models. What resulted was a sort of “least common denominator” experience that was unsatisfactory to anyone who was already familiar with the underlying repository model. Third, in many places VCM 1.0 was trying to be “too helpful” by providing numerous built in mechanisms. While this potentially allowed rapid integration for some repositories, in general one ended up having to fight this helpfulness due to subtle semantic differences between repositories. By contrast, in VCM 2.0 the repository integrator will always be “in charge”.

Approach

Our technical approach to this problem has two parts - a common base integration API, together with an extension mechanism. Repository vendors implement a simple compact base API, which provides basic functionality. The vendor then uses the extension mechanism to provide a higher level of integration to achieve the rich integrated experience provided by the unique benefits of the repository/configuration management/workflow solution. This entails writing tool plugin views, reusing common views provided by Eclipse, and integrating vendor specific function into the appropriate extension points in Eclipse. This approach is consistent with the overall tool integration strategy for Eclipse, and allows each vendor to decide how rich and how integrated an experience they will provide to their customers. It also allows staged development, where increasingly rich plugins can be provided over time. Further, it allows different adapter implementations to be produced for the same repository that have different personalities... for example one could produce a CVS adapter designed for CVS hackers, or another for novice users. Both work with CVS, but provide different user experiences.

Timeline

Our plan is to have the VCM 2.0 design closed off by end of year, and an initial cut of our new CVS adapter written for VCM 2.0 in that same time frame. We are eager to work with repository vendors in the context of the Eclipse Project at eclipse.org in that same time frame, in order to validate our design, and to ensure that there will be first class integrations from the major vendors for the release of Eclipse 2.0. 

Current State 

The work is still at an early stage and we expect changes to occur, in particular in the areas of labels (a.k.a. tags). We want this API evolution process to be driven by the requirements of repository vendors. By mid November we hope to be releasing to dev.eclipse.org a preliminary code drop that could be used for prototyping repository providers. We expect that this will help clarify the story, since code speaks louder than words. 

Architecture

The VCM 2.0 story can be broken down into the following pieces. 

VCM Core

  • VCM 2.0 will provide a base API (ITeamProvider interface, included below) representing the core set of VCM operations. 
  • All providers must implement this interface. 
  • An Eclipse project will be associated with one and only one ITeamProvider instance. 
  • There will be support for looking up an ITeamProvider instance given a project. 
In effect, ITeamProvider describes the abstract VCM model that other plugins can rely on for performing repository neutral operations. For example, a headless ISV consumer of this API could use it for writing build tools, code generation, etc. It is up to each repository vendor to implement this interface within the prescribed pre and post conditions, mapping the operations onto their native repository function. 

VCM UI 

  • There will be a mechanism by which a provider can offer up a Team menu that other plugins can include in their views. There will be a standard menu which a provider may choose to use wholly, supplement with additional operations, or replace entirely. 
  • Through this menu mechanism VCM acts as the intermediary between the third-party plugin that wishes to include VCM operations in their view, and the provider for that project who can offer up a Team menu specific to the workflows of their repository type. This allows repository specific VCM operations to be populated in views where the plugin writer and the repository provider don't know about each other. 
  • VCM will supply some standard views that repository providers may wish make use of. At present this list includes the Synchronization view from Eclipse 1.0 and the History view. In order to use these views, the repository provider will need to conform to additional APIs. Customization or subclassing may also be required. This offers a code reuse story for leveraging common views so that all repository providers don't need to write each from scratch. 
  • Alternatively, providers may wish to write their own custom views. This might be required in cases where the provider is unable to conform to the additional API, or in cases where the provider wishes to supply a view which is either richer or works substantially different than the Eclipse VCM supplied view. In all cases, it is the provider who is in charge. 
  • Decorators can be implemented to show VCM related information of a resource, for example in the Eclipse navigator. 
  • There will be an update mechanism to inform listeners of changes to the implied VCM properties (e.g. whether a resource is checked out or not). This would be used, among other places, to update the resource decorators above. 

The figure below shows this architectural separation for two suggested repositories, CVS and ClearClase.

The dashed boxes denote those pieces that a repository integrator must implement. For example for ClearCase, one would implement the VCM Core APIs, as denoted by the box CC Impl, as well as certain UI components, as denoted by CC UI. The vendor has opportunity to make repository specific calls in order to support their UI components. However, third party tools remain agnostic with regards to individual repository APIs and semantics. The amount of effort required to implement the UI pieces will depend whether one wishes to leverage the Eclipse VCM supplied UI components, or whether one wishes to implement custom UI components that better express the workflow of that repository type. Together, the VCM Core and UI architectures provide the pervasiveness required for a well-integrated VCM experience, with the customization required for rich repository integration.

The vendor has opportunity to make repository specific calls in order to support their UI components. However, third party tools remain agnostic with regards to individual repository APIs and semantics. The amount of effort required to implement the UI pieces will depend whether one wishes to leverage the Eclipse VCM supplied UI components, or whether one wishes to implement custom UI components that better express the workflow of that repository type. 

Together, the VCM Core and UI architectures provide the pervasiveness required for a well integrated VCM experience, with the customization required for rich repository integration. Included below is the interface ITeamProvider, the 'core' API described previously. As mentioned earlier, this is just a first cut and will be undergoing change. Other APIs supporting associating a provider with a project, looking up a provider for a project, Synchronization view, History view, and decorators will be coming.

For a sneak preview of the provider API see ITeamProvider