[platform-vcm-dev] Team Support - TO DO LIST

["Jean-Michel Lemieux/OTT/OTI" <Jean-Michel_Lemieux@xxxxxxx>]

Hi Team^2,

It would be great if the Team Support community could put together a small plan to outline our work items for the next couple of months. My hope is that this will provide the Team Support (a.k.a VCM) community with an idea of the dependencies and chronological ordering of the work items. For some of the big work items, I would expect that a proposal/outline of the work would be posted. A proposal/outline can be as simple as a couple of use-cases that demonstrates the feature.

What'ya think?

Here is the first try, I can merge comments and post a completed version to our web site next week.

-- jean-michel

============================================================================================

Team Core:
==========

1. Add synchronization APIs to core. 

This inclues methods for local state queries and chache refreshed (isCheckedOut, hasRemote), APIs for remote browsing, and algorithms for determining the relative synchronization of a resource using a local, base, and remote states. These APIs will support the interesting UI components that we want to build (e.g. sync view, generic-decorators, and remote browsing). A proposal for this API will be posted soon.

2. ValidateSave

This will allow a Team provider to perform a checkout _before_ the core resources plug-in tries to set contents of a resource. ValidateSave support will allow plug-ins such as jdt to perform programmatic resource modifications (e.g. refactoring) and coexist nicely with a pessimistic Team provider. A proposal for this API will be posted soon. (dependency on Core Resources)

3. ValidateEdit

This will allow a UI component, mostly for editors, to include a Team provider in the decision of whether a file can be edited or not. The Team UI will implement an extension point in the Workbench called validateEdit and can perform Team related prompts and operations to allow a file to be edited. A proposal for this API will be posted soon. (dependency on Workbench)

4. Transient resources

How to handle resources that the user or a plugin has defined as transient (e.g. should not be shared with a team).

5. Project descriptions

Persisting project descriptions.

Team UI:
========

1. Synchronization viewer. This work will proceed in stages with the first objective to have sync view with similar functionality as in R1.0. In parallel with the sync view work we will be providing feedback to the compare component. As the compare component changes the sync view will incrementally catch-up to the changes.

2. Generic decorators will be developed as soon UI releases the decorator support. (dependency on UI)

3. The current default actions (used by the examples) default to depth INFINITE on all operations. There should be seperate actions or a dialog to prompt the user.

4. Integrate with project natures UI support (dependency on UI)

Examples:
=========

The examples will continue to evolve. As new APIs are introduced the examples will provide an easy way of creating a reference implementation that can help validate the Team APIs.

CVS:
====

The focus here will be to self-host using this provider as of today. This means that features and bugs that affect self-hosting will have a high-priority.

 History viewer (multi-line)
 Create patch support
 UI for picking file type for CVS add
 Incrementaly improve repo browser
 Sync view
 Advanced versus basic CVS mode 
 Branch support (we need much improvement here, our R1.0 workflows we extremely un-intuitive)
 Full modules?
 SSH2 support in extssh?
 Merging a branch into the workspace (hopefully using the sync view and the sync API)
 Watch/edit