# Team support

The Eclipse Team support 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 worflows that we have found are useful for team plug-ins.

This goal is accomplished by supplying several building blocks:

- Repository Providers

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

- Resource Management

  > 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 metafiles 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 extenstion.

- Synchronization Support [new in 3.0]

  > 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 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. For example, one could install a CVS client designed for experts and a different one for novice users.