platform-team/team3.0/old/plan.html - gerrit/www.eclipse.org/eclipse - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
 <title>Team 3.0</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>

 <body>
 <h1>Team 3.0 </h1>
 <p><strong>Disclaimer</strong>: This document 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.</p>
 <h2>Long Term Goals</h2>
 <p>Here is a summary of the areas that Team is focusing on for 3.0.</p>
 <ul>
   <li>Provide the level of control over resource management required by repository
     providers.</li>
   <li>Provide UI support to enable repository providers to integrate well into
     Eclipse.</li>
   <li>Ongoing support of CVS but no major developement</li>
   <li>Support other Team related funtionality such as target management?</li>
 </ul>
 <p>The following sections describe each of these areas in more detail.</p>
 <h3>Resource Control for Repository Providers</h3>
 <p>Different repository providers desire different levels of control over version
   controlled resources. Currently, there are several facilities that provide a
   certain degree of provider control (e.g. move/delete hook, file modification
   validator, team-private, phantoms). This is a rather piecemeal approach that
   still does not provide enough control (e.g. copy sementics, missed deltas).
   These facilities should be consolodated and should provide the repository provider
   with the level of control they require to work optimally.</p>
 <p>Here is a list of some of the known problem areas that should be addressed
   by work in this area:</p>
 <ul>
   <li>copy sematics (akin to move/delete control already provided)</li>
   <li>session and persistant property management</li>
   <li>permissions</li>
   <li>integration of local history and remote history</li>
   <li>workspace/resource locking (which relates to multi-threading possibilities)</li>
   <li>non-local resources (what is a non-local resource and what is a phantom)</li>
   <li>hidden resources (aka team-private)</li>
   <li>missing deltas because the providers plugin is not loaded</li>
   <li>stychronizer and phantoms</li>
 </ul>
 <p>The first step is to capture the above in a form that can be used to gauge
   how mush work is involved and the impact on Core (where most of the funtionality
   will come from).</p>
 <h3>UI Support for Repository Provider Workflows</h3>
 <p>Although each repository provider is unique, there is common ground between
   them. Our goal should be to provide integration points that allow the uniqueness
   of each repository provider to be realized in Eclipse but also to provide common
   UI pieces that will simplify the implementation efforts of some or all repository
   providers. </p>
 <ul>
   <li>plugin discovery and enabling</li>
   <li>roles</li>
   <li>view/editor integration</li>
   <li>dynamic views</li>
   <li>keybindings</li>
   <li>sharing workspace setup</li>
   <li>compare infrastructure</li>
   <li>synchronization infrastructure</li>
   <li>file types/ignore patterns</li>
   <li>userid/password management</li>
 </ul>
 <p>The first step is to understand how each of these areas can help repository
   providers and also to estimate the effort required to provide them. Most of
   these items involve multiple components (Core, Team, Compare, UI, Update) and
   will effect API.</p>
 <h3>CVS</h3>
 <p>There is not a lot of priority items that remains for the CVS plugin. Here
   are a list of several items being considered:</p>
 <ul>
   <li>CVS Repositories View and Tag Management</li>
   <li>infrastructure to prevent regressions in functionality and performance</li>
   <li>separate from SDK</li>
   <li>working with multiple respositories</li>
   <li>improved branching/merging support</li>
 </ul>
 <p>The CVS plugin will also need to conform to any changes that come about due
   to Team/Platform changes.</p>
 <h3>Other Team Related Areas</h3>
 <p>It is not clear at this time if there is enough of a demand for target management
   to justify making it a priority. It sure would be nice to have though. It would
   also be nice to know if there are other Team facilities that could be provided.</p>
 <h2>Near term work items</h2>
 <h3>Synchronize View</h3>
 <ol>
   <li> Sync view usability
 <ul>
   <li> table view for handling smaller number of sync elements (navigating sparse
     tree is a pain)</li>
   <li> text editor should be fully functional</li>
   <li> work flow
     <ul>
       <li> turning off builds when updating individual changes</li>
       <li> should navigator also act as sync view? JM's recent changes.</li>
     </ul>
   </li>
 </ul>
   <li>Sync view API - people want to reuse that good work </li>
   <ul></ul>
   <li> Sync view as separate pieces

 <ul>
   <li> work with UI team to sort out how to wire together navigator, outline,
     text editor</li>
   <li> also solves problem of sync view being too big for default view locations</li>
   <li> also, compare editors are odd as editors</li>
 </ul>
 </ol>
 <h3>Investigate Improving Repository Provider Support</h3>
 <ol>
   <li>End to end scenarios as they are and as we would like to see them (roles,
     editor integration, compare/sync, update, etc). The scenarios to consider
     are things like:</li>
 <ul>
   <li>How are projects shared (differs by repository provider)</li>
   <li>How are operations perform (main menu, context menu, key-strokes)</li>
   <li>Where are operations performed (view, editor, perspective, roll)</li>
   <li>Resource synchronization/merging</li>
   <li>comparing</li>
   <li>remote browsing</li>
   <li>patching (do others use Team&gt;Apply Patch?)</li>
   <li>disconnection from version control (may or may not be supported)</li>
   <li>sharing workspace setup (project sets)</li>
   <li>sharing project setup (properties, linked resources)</li>
   <li>transations (validateSave/Edit)</li>
     <li>file type management</li>
   <li>ignores</li>
 </ul>
   <li>Requirements for consolodated resource control</li>
 </ol>
 <h3>Polish CVS</h3>
 <p>Work can be done in the background while other areas involving multiple components
   are being fleshed out. </p>
 <ol>
   <li>CVS Repositories view and taga management.</li>
   <li>Perfomance benchmarks</li>
 </ol>
 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
	<html>
	<head>
	<title>Team 3.0</title>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	</head>

	<body>
	<h1>Team 3.0 </h1>
	<p><strong>Disclaimer</strong>: This document 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.</p>
	<h2>Long Term Goals</h2>
	<p>Here is a summary of the areas that Team is focusing on for 3.0.</p>
	<ul>
	<li>Provide the level of control over resource management required by repository
	providers.</li>
	<li>Provide UI support to enable repository providers to integrate well into
	Eclipse.</li>
	<li>Ongoing support of CVS but no major developement</li>
	<li>Support other Team related funtionality such as target management?</li>
	</ul>
	<p>The following sections describe each of these areas in more detail.</p>
	<h3>Resource Control for Repository Providers</h3>
	<p>Different repository providers desire different levels of control over version
	controlled resources. Currently, there are several facilities that provide a
	certain degree of provider control (e.g. move/delete hook, file modification
	validator, team-private, phantoms). This is a rather piecemeal approach that
	still does not provide enough control (e.g. copy sementics, missed deltas).
	These facilities should be consolodated and should provide the repository provider
	with the level of control they require to work optimally.</p>
	<p>Here is a list of some of the known problem areas that should be addressed
	by work in this area:</p>
	<ul>
	<li>copy sematics (akin to move/delete control already provided)</li>
	<li>session and persistant property management</li>
	<li>permissions</li>
	<li>integration of local history and remote history</li>
	<li>workspace/resource locking (which relates to multi-threading possibilities)</li>
	<li>non-local resources (what is a non-local resource and what is a phantom)</li>
	<li>hidden resources (aka team-private)</li>
	<li>missing deltas because the providers plugin is not loaded</li>
	<li>stychronizer and phantoms</li>
	</ul>
	<p>The first step is to capture the above in a form that can be used to gauge
	how mush work is involved and the impact on Core (where most of the funtionality
	will come from).</p>
	<h3>UI Support for Repository Provider Workflows</h3>
	<p>Although each repository provider is unique, there is common ground between
	them. Our goal should be to provide integration points that allow the uniqueness
	of each repository provider to be realized in Eclipse but also to provide common
	UI pieces that will simplify the implementation efforts of some or all repository
	providers. </p>
	<ul>
	<li>plugin discovery and enabling</li>
	<li>roles</li>
	<li>view/editor integration</li>
	<li>dynamic views</li>
	<li>keybindings</li>
	<li>sharing workspace setup</li>
	<li>compare infrastructure</li>
	<li>synchronization infrastructure</li>
	<li>file types/ignore patterns</li>
	<li>userid/password management</li>
	</ul>
	<p>The first step is to understand how each of these areas can help repository
	providers and also to estimate the effort required to provide them. Most of
	these items involve multiple components (Core, Team, Compare, UI, Update) and
	will effect API.</p>
	<h3>CVS</h3>
	<p>There is not a lot of priority items that remains for the CVS plugin. Here
	are a list of several items being considered:</p>
	<ul>
	<li>CVS Repositories View and Tag Management</li>
	<li>infrastructure to prevent regressions in functionality and performance</li>
	<li>separate from SDK</li>
	<li>working with multiple respositories</li>
	<li>improved branching/merging support</li>
	</ul>
	<p>The CVS plugin will also need to conform to any changes that come about due
	to Team/Platform changes.</p>
	<h3>Other Team Related Areas</h3>
	<p>It is not clear at this time if there is enough of a demand for target management
	to justify making it a priority. It sure would be nice to have though. It would
	also be nice to know if there are other Team facilities that could be provided.</p>
	<h2>Near term work items</h2>
	<h3>Synchronize View</h3>
	<ol>
	<li> Sync view usability
	<ul>
	<li> table view for handling smaller number of sync elements (navigating sparse
	tree is a pain)</li>
	<li> text editor should be fully functional</li>
	<li> work flow
	<ul>
	<li> turning off builds when updating individual changes</li>
	<li> should navigator also act as sync view? JM's recent changes.</li>
	</ul>
	</li>
	</ul>
	<li>Sync view API - people want to reuse that good work </li>
	<ul></ul>
	<li> Sync view as separate pieces

	<ul>
	<li> work with UI team to sort out how to wire together navigator, outline,
	text editor</li>
	<li> also solves problem of sync view being too big for default view locations</li>
	<li> also, compare editors are odd as editors</li>
	</ul>
	</ol>
	<h3>Investigate Improving Repository Provider Support</h3>
	<ol>
	<li>End to end scenarios as they are and as we would like to see them (roles,
	editor integration, compare/sync, update, etc). The scenarios to consider
	are things like:</li>
	<ul>
	<li>How are projects shared (differs by repository provider)</li>
	<li>How are operations perform (main menu, context menu, key-strokes)</li>
	<li>Where are operations performed (view, editor, perspective, roll)</li>
	<li>Resource synchronization/merging</li>
	<li>comparing</li>
	<li>remote browsing</li>
	<li>patching (do others use Team>Apply Patch?)</li>
	<li>disconnection from version control (may or may not be supported)</li>
	<li>sharing workspace setup (project sets)</li>
	<li>sharing project setup (properties, linked resources)</li>
	<li>transations (validateSave/Edit)</li>
	<li>file type management</li>
	<li>ignores</li>
	</ul>
	<li>Requirements for consolodated resource control</li>
	</ol>
	<h3>Polish CVS</h3>
	<p>Work can be done in the background while other areas involving multiple components
	are being fleshed out. </p>
	<ol>
	<li>CVS Repositories view and taga management.</li>
	<li>Perfomance benchmarks</li>
	</ol>
	</body>
	</html>