| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| |
| <head> |
| <title>Team/CVS Possibilities</title> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> |
| </head> |
| |
| <body bgcolor="#ffffff" text="#000000"> |
| <p>Back to <a href="../archivedReleases.php">Archived Releases</a></p> |
| <table border="0" cellspacing="5" cellpadding="2" width="100%"> |
| <tbody> |
| <tr> |
| <td align="left" valign="top" bgcolor="#0080c0"> <b><font color="#ffffff" face="Arial,Helvetica"> |
| Team/CVS Possibilities</font></b></td> |
| </tr> |
| <tr> |
| <td width="98%"> <h4>Team</h4> |
| <p>These are the areas of interest in Team for possible future work.</p> |
| <ul> |
| <li><strong>Improved sync view</strong>: 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. </li> |
| <li><strong>Merging vs Syncing</strong>: Currently we have 3 types of |
| compare views: sync, merge and compare. It would be nice if these |
| wee consolidated.</li> |
| <li><strong>Target Management</strong>: 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.</li> |
| <li> <strong>Ensuring Providers get resource deltas</strong>: 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).</li> |
| <li><strong>Permissions support</strong>: See bug <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=22923">22923</a> |
| </li> |
| <li><strong>File Types</strong>: See bug ?????</li> |
| </ul> |
| <p><strong>CVS</strong></p> |
| <p>These are the areas of interest in CVS for possible future work.</p> |
| <ul> |
| <li><strong>Defects</strong>: There are over 300 open defects in bugzilla. |
| This number should be reduced.</li> |
| <li><strong>Performance</strong>: 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.</li> |
| <li><strong>Improved tag management</strong>: 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.</li> |
| <li><strong>Checkout</strong>: 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.</li> |
| <li><strong>Keybindings</strong>: It would be nice to have keybindable |
| CVS actions.</li> |
| <li><strong>Patches</strong>: 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.</li> |
| <li><strong>EXT connection method</strong>: 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).</li> |
| <li><strong>Support shallow operations</strong>: 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.</li> |
| <li><strong>Alternate view of projects and tags in repositories view</strong>: |
| 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.</li> |
| <li><strong>Keyword Substitution mode management</strong>: The wizard |
| for this is a bit confusing in places. Also, it should be available |
| from the sync view for outgoing additions.</li> |
| <li><strong>CVS API</strong>: 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.</li> |
| <li><strong>Working against multiple repositories</strong>: 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).</li> |
| </ul></td> |
| </tr> |
| </tbody> |
| </table> |
| |
| </body> |
| </html> |
