Back to Archived Releases

Team/CVS Possibilities


These are the areas of interest in Team for possible future work.

  • Improved sync view: There are in the order of 70 open bug reports against the CVS sync view and many of them are not resolvable given the current infrastructure. However, this functionality is actually more general than just CVS. A good syncing story would benefit all repository providers and possibly target management as well.
  • Merging vs Syncing: Currently we have 3 types of compare views: sync, merge and compare. It would be nice if these wee consolidated.
  • Target Management: A unfied API for target management would benefit many tools build on Eclipse as well as users. The current incarnation is usable for WebDAV but barely usable for FTP.
  • Ensuring Providers get resource deltas: There are some cases where a repository provider may miss a delta they are interested in because their plugin was not loaded when the delta occured. Although they can still get this delta when they are loaded by registering as a save participant, it may be too late (i.e. CVS folders may be visible).
  • Permissions support: See bug 22923
  • File Types: See bug ?????


These are the areas of interest in CVS for possible future work.

  • Defects: There are over 300 open defects in bugzilla. This number should be reduced.
  • Performance: We made some good progress in 2.1 on performance. Some time should be spent ensuring that all of CVS is scalable/peformant. Also, it would be beneficial to have automated performance tests to ensure that performance gains are not lost by future bug fixes, etc.
  • Improved tag management: This area is very confusing for the user and certain situations (e.g. no remote .project file) can complicate things even more. Also, tags are only managed for root folders which prevents some users from gaining the full potential of the repo view.
  • Checkout: There are currently several mechanisms for checking out resources which leads to use confusion. Consolidating into Checkout and Checkout As would improve the situation and should not be complicated to implement.
  • Keybindings: It would be nice to have keybindable CVS actions.
  • Patches: Although our patching is good there are still a couple of restrictions that should be little effort to fix. We should allow added files in added directories and increase the places where you can created a patch (e.g. investigate application of the patch from the sync view). Also, there is revision information in the patch that could help in certain situations when the patch is applied.
  • EXT connection method: Support for EXT was improved in 2.1 but is still rough. There are approximatly 10 open bugs for this area. The biggest problem is communicating error conditions to the user (i.e. current failure yields confusing message).
  • Support shallow operations: CVS currently performs all operations deeply. We should allow the user to sync/commit/update/add only a folder and not it's subfolders. This is especially relevant for those who work in large Java projects as syncing a package will sync all subpackages as well.
  • Alternate view of projects and tags in repositories view: Currently the repo view shows all the projects grouped by branch and versions grouped by project. There have been several requests for the converse of both cases (i.e. branches groupd by project and projects grouped by version). Supporting these alternate views would allow a user to easily checkout multiple projects from the same version, for example.
  • Keyword Substitution mode management: The wizard for this is a bit confusing in places. Also, it should be available from the sync view for outgoing additions.
  • CVS API: An API for CVS would allow others to write custom tools specific to their needs. For example, we have already written several tools for RelEng that provide functionality that is specific to the Eclipse build process. Without an API, other organizations will not likely risk doing this. Given an API, there is also possible that others may write useful CVS tools and make them available to the community.
  • Working against multiple repositories: It seems to be fairly common that users who work woth a repository that is slow to connect to will work with a local repository on a day to day basis and ocasionally commit there changes against the remote repository. Although there is some support for this in Eclipse, it is still difficult to do (and there are some performance bottlenecks as well). It would not be much effort to improve the support to a level that is usable. Full support would probably be a considerable effort (but neat try).