Team 3.0

Disclaimer: This document does not represent a commitment to pursue any of the below mentioned areas. It is a draft of potential future areas of focus for the Eclipse Team component.

Long Term Goals

Here is a summary of the areas that Team is focusing on for 3.0.

• Provide the level of control over resource management required by repository providers.
• Provide UI support to enable repository providers to integrate well into Eclipse.
• Ongoing support of CVS but no major developement
• Support other Team related funtionality such as target management?

The following sections describe each of these areas in more detail.

Resource Control for Repository Providers

Different repository providers desire different levels of control over version controlled resources. Currently, there are several facilities that provide a certain degree of provider control (e.g. move/delete hook, file modification validator, team-private, phantoms). This is a rather piecemeal approach that still does not provide enough control (e.g. copy sementics, missed deltas). These facilities should be consolodated and should provide the repository provider with the level of control they require to work optimally.

Here is a list of some of the known problem areas that should be addressed by work in this area:

• copy sematics (akin to move/delete control already provided)
• session and persistant property management
• permissions
• integration of local history and remote history
• workspace/resource locking (which relates to multi-threading possibilities)
• non-local resources (what is a non-local resource and what is a phantom)
• hidden resources (aka team-private)
• missing deltas because the providers plugin is not loaded
• stychronizer and phantoms

The first step is to capture the above in a form that can be used to gauge how mush work is involved and the impact on Core (where most of the funtionality will come from).

UI Support for Repository Provider Workflows

Although each repository provider is unique, there is common ground between them. Our goal should be to provide integration points that allow the uniqueness of each repository provider to be realized in Eclipse but also to provide common UI pieces that will simplify the implementation efforts of some or all repository providers.

• plugin discovery and enabling
• roles
• view/editor integration
• dynamic views
• keybindings
• sharing workspace setup
• compare infrastructure
• synchronization infrastructure
• file types/ignore patterns
• userid/password management

The first step is to understand how each of these areas can help repository providers and also to estimate the effort required to provide them. Most of these items involve multiple components (Core, Team, Compare, UI, Update) and will effect API.

CVS

There is not a lot of priority items that remains for the CVS plugin. Here are a list of several items being considered:

• CVS Repositories View and Tag Management
• infrastructure to prevent regressions in functionality and performance
• separate from SDK
• working with multiple respositories
• improved branching/merging support

The CVS plugin will also need to conform to any changes that come about due to Team/Platform changes.

Other Team Related Areas

It is not clear at this time if there is enough of a demand for target management to justify making it a priority. It sure would be nice to have though. It would also be nice to know if there are other Team facilities that could be provided.

Near term work items

Synchronize View

1. Sync view usability
   • table view for handling smaller number of sync elements (navigating sparse tree is a pain)
   • text editor should be fully functional
   • work flow
     • turning off builds when updating individual changes
     • should navigator also act as sync view? JM's recent changes.
2. Sync view API - people want to reuse that good work
3. Sync view as separate pieces
   • work with UI team to sort out how to wire together navigator, outline, text editor
   • also solves problem of sync view being too big for default view locations
   • also, compare editors are odd as editors

Investigate Improving Repository Provider Support

1. End to end scenarios as they are and as we would like to see them (roles, editor integration, compare/sync, update, etc). The scenarios to consider are things like:
• How are projects shared (differs by repository provider)
• How are operations perform (main menu, context menu, key-strokes)
• Where are operations performed (view, editor, perspective, roll)
• Resource synchronization/merging
• comparing
• remote browsing
• patching (do others use Team>Apply Patch?)
• disconnection from version control (may or may not be supported)
• sharing workspace setup (project sets)
• sharing project setup (properties, linked resources)
• transations (validateSave/Edit)
• file type management
• ignores
2. Requirements for consolodated resource control

Polish CVS

Work can be done in the background while other areas involving multiple components are being fleshed out.

1. CVS Repositories view and taga management.
2. Perfomance benchmarks