The Eclipse version control support, via the team plug-ins, defines API that allow plug-ins to integrate the function of a versioning and configuration management repository. The function provided by a repository fundamentally affects the user workflow, since there are additional steps for retrieving files, comparing their content with local content, versioning them, and returning updated files to the repository. The goal of the team plug-in API is to be passive enough to allow repository plug-in providers to define their own workflow so that users familiar with their product can use the platform in a similar fashion and provide support for workflows that we have found are useful for team plug-ins.
This goal is accomplished by supplying several building blocks:
A repository provider allows synchronization of workspace resources with a remote location. At a minimum it allows pushing resources in the workspace to a remote location and pulling resources from a remote location into the workspace. A repository provider is associated with a project and controls the resources in the project by optionally providing a FileModificationValidator and IMoveDeleteHook. There is only one repository provider associated with each project. A user associates a repository provider with a project by providing a IConfigurationWizard. Repository providers can also participate in exporting and importing of projects into the workspace via the team project set feature. To support this a repository provider should implement a ProjectSetCapability.
Allows other plug-ins to indicate special handling of resources with respect to team operations. The repository provider can mark resources as team-private which essentially hides the resource from other plug-ins. This is done via the IResource#setTeamPrivateMember method and is commonly done to hide repository provider specific meta-files from the user. Also, builders will often mark build output as derived which is a hint to a repository provider that the resource is transient and could be ignored by the repository provider. A provider can check this flag on a resource via the IResource#isDerived method.
In addition, other plug-ins can add provide hints to the repository provider about file type information via the org.eclipse.team.core.fileTypes extension and about common files that should be ignored by the repository via the org.eclipse.team.core.ignore extension.
Synchronize support provides classes and interfaces for managing dynamic collections of synchronization information (SyncInfo, SyncInfoSet). This support helps you manage information about variants of the resources in the workspace. For example, with FTP you could store timestamps for the latest remote file and the base for the currently loaded resource. Synchronization support provides APIs to help manage and persist resource variants and display synchronization state to the user.
The logical model integration support defines API that allows logical models to participate in team operations. In model based views, model providers can use this support in order to have team decorations and operations appear on their model elements. In resource based views (e.g. Resource Navigator), model providers can use this support to validate that operations performed on resources will not corrupt the model and to ensure that all the resources that constitute a model element are included in team operations. For team merge operations, the API allows model providers to use model semantics during merge operations and to participate in the preview of merge operation. The description of the support for logical model integration is divided into a Repository Roadmap for Logical Model Integration and a Model Roadmap for Logical Model Integration.
The UI support is also structured passively. Placeholders for team provider actions, preferences, and properties are defined by the team UI plug-in, but it's up to the team plug-in provider to define these UI elements. The team UI plug-in also includes a simple, extendable configuration wizard that lets users associate projects with repositories. Plug-ins can supply content for this wizard that let the user specify repository specific information.
Multiple repository providers can coexist peacefully within the platform. In fact, it's even possible to have different client implementations for the same repository installed.