Team
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 ?????
CVS
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).
|