Eclipse Team Component Roadmap

Summary:
This document outlines the current problems with Team and CVS support in Eclipse. It also suggests some important new Team features that should be considered for future releases of the platform. This 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.

Last Modified: April 17, 2003

Table of Contents:

Team Plugin
Resources Plugin
UI Plugin
Team APIs
Target Management
Enhanced collaboration support
What's next for CVS

Team Plugin

1. Dispatching project based resource control extension points

The Team plugin currently extends several core extension points for resource management (file modification validator, team hook, move/delete hook). This is a rather piecemeal approach that still does not provide enough control (e.g. copy semantics, missed deltas). These facilities should be consolidated and should provide the repository provider with an increased integration with the resources plugin. Some examples of existing problems:

• Until the Team plugin is loaded there are no hooks registered. This is very problematic when you consider that the need for implementing a hook is usually to provide some meta file sanity on the versioned resources. And missing resource changes can result in inconsistent provider meta file state.
• There are missing cases where the provider needs more control over resources (e.g. copy)
• Are the hooks really Team specific or should they instead be available to other types of plugins?
As a case in point, PDE is currently a repository provider to gain some control over binary projects.
2. Sync view (non-API, usability, threading, pervasive sync)

One of the most impressive features of the Team story is the excellent integration with compare technology. CVS users can visually compare, merge, and integrate changes within the workbench. This makes CVS very accessible to many users that never would of though of using CVS via the command line. However, even with the current high level of integration of the compare infrastructure there is much room for improvement. Most of the proposed sync enhancements are meant to improve a user's awareness of what others on their team are doing. With this additional sync awareness and the suggestions mentioned in the Expanded Collaboration Support section, the Team component will enable a unique and very rich collaboration infrastructure in Eclipse. The appendix contains a detailed list of problems with the sync view but here is how we would like to see the sync view evolve:

• Split the current sync view into several pieces that work together. This would include a synchronize view that displays a 'live' sync view of resources in the workspace. And compare editors would be opened to edit sync nodes.
• There is no API for reporitory providers to re-use the sync view. This inhibits other providers from benefiting from the sync support.
• Provide a better representation of changes than a full tree view. Possible alternatives could be to use a compact tree or table.
• Additional information about sync changes should be available to understand how team members are making changes that affect your work (e.g. user names, code changes, comments, activities).
• There should be different places for showing sync information (tasks in editors, sync view, decorations).
• The view that shows sync state for changes should be live and show outgoing changes without having to synchronize with the server.
• Calculate the incoming changes in the background
3. It would be useful for the Team to help the community start a repository provider plugin for Subversion (e.g. the replacement for CVS) and ensure that the ClearCase plugin is as well integrated as CVS.
4. Logical to physical mapping has always been an outstanding problem in Eclipse. Here are two examples:
   • In the Java packages explorer if you select a package then perform Team > Commit.. the action will perform the operation on all child resources of the package although visually the package really only contains immediate children.
   • Outgoing dirty indicators contributed by the CVS plugin decorate logical views because the decorator is based on the physical resource model.
5. Better understanding of end to end scenarios as they are and how they should be (roles, editor integration, compare/sync, update, etc). The scenarios to consider are things like:
   • How are projects shared (differs by repository provider)? Do we still need a Team > Share... menu item or are providers using their own mechanisms instead?
   • How are operations performed (main menu, context menu, key-strokes).
   • Where are operations performed (view, editor, perspective, roll)
   • Resource synchronization/merging
   • comparing
   • patching (do others use Team>Apply Patch?)
   • sharing workspace setup (project sets, properties, preferences)
   • sharing project setup (properties, linked resources)
   • transactions (validateSave/Edit)
   • file type management
   • ignored resources

Resources plugin

1. Resource history management in the resources plugin should be reviewed. Currently callers of IResource API decide on the history configuration of a resource and there is no way to impose a workbench wide policy - IResource.setContents(keepHistory). This is a very fragile mechanism because random plugins can delete history and users cannot configure their own versioning based rules. For example, local history could be purged on commit.



2. Permission support is missing from core which makes it impossible for plugins to synchronize the remote permissions with the local. This is really a pain when users put scripts/executables into a remote location as the subsequent retrieval
will not have the proper permissions.


3. Workspace locking granularity and deadlocks when plugins use their own locking mechanism. We have had many problems with the decorators with deadlock.



4. Copy semantics need to be integrated into team hooks. For example, most team providers have work to do on copy (e.g. handle meta files...) and are currently not given the chance to do so.



5. Should phantoms be considered as generalized synchronization mechanism and shown by viewers? Or are they a mechanism for synchronization providers. There is a good discussion about the role of phantoms in the platform. Are they a mechanism that plugins can use to store sync info or should they be the imposed method of storing sync info? Having phantoms as a first class synchronization concept in the platform would allow sync information to be available in any resource based view (e.g. the navigator) via phantoms. But realistically it is naive to think that team provider plugins must use phantoms to track synchronization information.



6. Team-private resources marking is problematic because there are cases (e.g. the plugin isn't loaded yet) were this story breaks down. Plugins wanting to mark resources as team-private must be allowed to do so without having to worry about plugin loading issues.



7. Aggressive builds - empty deltas or deltas with non-build specific information like sync changes.



8. Integration of local history and provider history (see Expanded Collaboration Support)



9. The use of linked resources can break validateSave/Edit and other Core hooks. Consider the scenario involving linking resources from a shared project into a non-shared project. Operations performed on the non-shared project may involve resources that are linked. Non of the Core hooks will be invoked for these resources even though they are under version control in another project.

UI plugin

1. UI Decorator support currently has several problems. The CVS decorator's performance has degregated from 2.0 to 2.1 and there still seems like there are some important changes required to make the decoration mechanism scalable.



2. Dynamic views or view re-use. Team would like to provide a sync view that can be re-used by several providers simultaneously activated in the workbench. For example, if you had CVS and FTP enabled for a project you would have two sync views.



3. Keyboard bindings for object contributions. Repository provides add their menu items to other views using popup menu object contibutions in plugin.xml. There actions are currently not key-binadable which requires providers to additionaly provide global actions for any key-bindable operations.
   
   
4. Access to Team operations from within an editor. Currently the user must perform team operations on a resource that appears in a view. It would simplify the user's workflow if there menu operations were also available in an editor.
   
   
5. Password clearing support from the UI. The core password facility is used by several plugins but there is no UI support for clearing the passwords known to the workspace. (Bug 8947)



6. Filter rules applied to object contributions. When an action is run from a view that is currently being filtered the action can only assume that all resources are being shown. For example, if a filter is applied to the navigator view and a users performs a commit on a folder the commit will apply to all children of the folder and not only the visible items.

Team APIs

There is a long history of VCM APIs in Eclipse :) In the early days of Eclipse we thought that an API was the foundation on which the Eclipse VCM support should be built and spent quite a while trying to realize this. That was Eclipse 1.0.

As a result of the 1.0 API, several repositories, including CVS, were forced to bend and contort to implement the API. And what ended up happening was that each repository wasn't able to fully expose their functionality within Eclipse. We had an API, but the repository integration within Eclipse was weak.

As part of the 2.0 release we shifted our priority from an API and concentrated instead on providing repositories the mechanisms for rich integration into the workbench (file system hooks, decoration, menu contributions, project association). Our goal was to ensure that any repository provider could integrate easily and show-off their cool features within the workbench. Based on the number of providers that have integrated with Eclipse in such a short period and the small number of questions we feel that we have succeeded.

Beyond 2.1 we want to improve and fix the problems with the existing integration mechanisms. In addition we would like to understand the community's need for VCM APIs. So far we aren't sure if people want an API for CVS (e.g. repository specific) or a more general API for VCM. There are obvious use cases that support the need of some flavour of APIs: (a) release engineering needs access to the repository, (b) 3rd parties could extend a repository providers integration by building new cool tools - see Hipikat, bug 24882, Jazz project, and many others, (c) headless control of the repository..

Our position on a general API for VCM is that we don't want to be the ones inventing or imposing an API because we know from experience that we shouldn't be in that business. It's up to the repository vendors to prove to us that there is buy in for such an API. Instead, if there was a reference implementation and an Eclipse plugin showing that (a) the API can be implemented, and (b) there is interest from other repository vendors to implement the API, we could then start investigating how to integrate the API into the Eclipse VCM deliverable.

The motivation for APIs is no longer based entirely on our desire to build *the* generic Team UI but instead to complement the current Team support (very rich integration story for providers) with an API story that can solve the above issues. We have learned our lesson and know that an API should never be the only option for providers to integrate into Eclipse, but that doesn't mean that it can't become *another* option.

The interest in JSR-147 is that it is a repository vendor approved API that is actually close to what we would need for generic access. See http://www.jcp.org/en/jsr/detail?id=147 for more details.

Target Management/Deployment

The Eclipse download page contains a link to a prototype for target management support. It includes ftp and dav as two supported targets. Given the new J2EE requirements we should investigate if there is a need for a real deployment story in Eclipse.

If there any push for making this prototype real we would have to:

• flush out the relationship between target providers and versioning providers (currently they are completely separate and target is implemented as a copy of the repository provider code).
• by getting rid of the duplicated target provider mapping code
• make the ftp and dav plugins product quality.

Expanded collaboration support

During the 2.0 timeframe the VCM component was renamed to Team to reflect the components problem domain as being more than versioning and configuration management. Unfortunately the only other avenue explored in the 2.0 release was Target Management. In the future the Team component should be the catalyst for platform changes that enable deep collaboration support in Eclipse. There are a number of existing projects that are focused on collaboration support in Eclipse and it isn't our intention of adding all the tools but instead ensuring that the support is available in Eclipse for building the tools. We have compiled the following wish list for expanded collaboration support.

1. Resource variant awareness

   We should investigate adding the metaphor that every resource has the potential for "variants" to exist. When a team works on a problem together the resources they create will always change over time: you can change a file and save it, add to a repository and someone else can change it, add to a web server via webdav and have someone else change it. We would like to focus increasing the users awareness about the variants and break down the barriers to having every tool that creates variants (local history, cvs, ftp, webdav) use a set of common mechanisms.

2. Editor change awareness and viewing support

   To support resource variant awareness editors could be enhancements to support viewing the variants. This would improve on the current problem of having dedicated compare text viewers for looking at changes but not being able to have full editor support in the viewers. Some options for editor support could include:

   • editor support for comparison via split pane (vertical/horizontal) or text markup (e.g. Word revision markings)
   • use of tasks to mark changes that other team members are making to an opened file
   • use of tasks to mark annotations (comments or other) that other team members are making to an opened file


3. Combined history support

   It should be possible to build views that show the combined list of variants for a resource. The input to the list can be one of many sources of variants. For example, the local history could be combined with the CVS resource history.

4. Support for both content and naming variants

Resources can either have their content changed or naming. The support for tracking these changes could be investigated.

5. API to support integration of collaboration tools into Eclipse

   Most collaboration tools (e.g. Jazz, Hipikat) built on Eclipse will require access to the variants that are stored in some team location. Currently the collaboration tools rely on the CVS plugin to fetch revision history, previous file contents, user names for resource variants. This makes the collaboration tools incompatible with other resource sharing tools (e.g. ClearCase, ftp, webdav). Having a suitable API for Team would help solve this current problem and help expand collaboration support in Eclipse.

What's next for CVS

1. The CVS plugin should not be part of the platform SDK. There should be a CVS component separate from VCM (Team). This would allow CVS to have a top level menu and in general allow other providers to be alone in the workbench.
2. CVS Repositories View and Tag Management
3. Infrastructure to prevent regressions in functionality and performance
4. Implementation of new Sync View APIs
5. Implementation of (if any) generic API
6. Improvement of CVS workflows for Eclipse developers (e.g. integration with Bugzilla and search capabilities)
7. Working with multiple respositories
8. Improved branching/merging support
9. Improved patch support (creating patches from sync view, applying patches via sync view).

Appendix

This is a summarized list of issues with the current sync view and associated bug reports:

Structure compare part has many usability problems

1. The problem is that the things you are interested in (the leaves of the tree) are continually scrolled out of view and separated by a great distance when the tree is expanded, making it hard to see at a glance what has changed. It also makes multi-selection operations very painful, for example comitting a set of related files that should have the same comment. (12453, 16249)
2. There are several also several expansion/selection usability problems with the part. (35187, 33041, 4931, 5431, 20847, 27237, 16249)
3. Synchronize view modes (filtering) and conflict workflows must be improved (10556, 9451, 139, 19712)

Finding the outgoing changes requires a long running operation

To commit outgoing changes you have to hit the server. This is really painful since the list of outgoing changes can be determined without considering the remote files.

Synchronization view doesn't fit with workbench view/editor paradigm

The sync view is essentially an editor and a view combined. Unfortunatly they don't quite work as any other view/editor combination in the workbench.What would happen if we split the structure compare away and made that a view on the sync states of all resources in the workbench and then allowed opening a compare editor (basically the bottom portion) when merging or viewing changes was required?

Background fetching of remote state

Currently when a project is synchronized the complete remote tree is fetched and a progress dialog is shown. The user can't perform any other operation while the remote tree is fetched. There is no reason why this couldn't be fetched in the backgroup without blocking the UI and would allow an awareness of what other people in the team are working on and help reduce the time needed to find out what others are doing.

Java text merge editor isn't real

Would like to use real editors for merging instead of the neutered ones currently used. For example, the java editor shown in the sync view looks real (e.g. syntax coloring) but is a scaled down java editor. This causes integration and context problems because it is very useful to try and write code in these editors without resorting to opening the file with the real java editor. Then going back to the sync view only to find that the file hasn't refreshed.

Compare editors (merge/compare) versus sync view

The terminology and look and feel of the merge editor and sync view is different. Basically a merge is the same as synchronizing except for the fact that you can't commit changes. Merging is already a tricky operation and having a conflicting usage model between the sync and merge makes it even harder. (35577)

Comparison criteria is not well integrated into compare

The comparison criteria that is used to calculate the sync state is hidden from the user and it isn't obvious for them when the criteria should be changed and what advantage it will have. (24887, 21612, 28143)

[CVS] Synchronizing against an existing project is not well supported

This is somewhat of a CVS problem but relates to the more general issue of when to change the comparison criteria. (21612)