diff options
Diffstat (limited to 'tests/org.eclipse.team.tests.cvs.core/toc.html')
| -rw-r--r-- | tests/org.eclipse.team.tests.cvs.core/toc.html | 1955 |
1 files changed, 0 insertions, 1955 deletions
diff --git a/tests/org.eclipse.team.tests.cvs.core/toc.html b/tests/org.eclipse.team.tests.cvs.core/toc.html deleted file mode 100644 index 424a7c69d..000000000 --- a/tests/org.eclipse.team.tests.cvs.core/toc.html +++ /dev/null @@ -1,1955 +0,0 @@ -<html><head><title>Team/CVS Test Plan</title><style type='text/css'>h1 {color: white;background-color: #0080C0;padding-left: 1ex;padding-right: 1ex;}h1 {font-weight: bold;padding-top: 0.5ex;padding-bottom: 0.5ex;margin-top: 0;}</style></head><body> - -<!-- KEEP START --> -<h1>Eclipse Team and CVS 3.0 Test Plan</h1> -This plan contains a detailed listing of the features available in the -Eclipse CVS plug-in. There are some items that don't have many steps -but are meant as a reminder that the features exist and should be -tested. If you want to help, please feel free to hammer away on some -bits of functionality.<br> -<br> -For a more verbose explanation of the CVS plug-in please refer to our -documentation.<br> -<h2>CVS Server Versions</h2> -We focus our testing on the latest stable *nix server version. We will -however sniff test the latest developer *nix server and the cvsnt -server. In addition, we will run our automated tests on all three -flavours. The current server lineup is:<br> -<br> -Latest Stable: <span style="font-weight: bold;">1.11.16</span><br> -Latest Development: <span style="font-weight: bold;">1.12.8</span><br> -CVS NT: <strong>2.0.41a</strong> -<h2>Testing Tips</h2> -<ul> - <li><font color="#000000">test corner cases</font></li> - <li>test setups which we typically don't use during development (for -example no Plug-in developement)</li> - <li><font color="#000000">handling of error situations</font> - <ul> - <li><font color="#000000">watch log</font></li> - <li><font color="#000000">error messages</font></li> - </ul> - </li> -</ul> -<ul> - <li>Whenever you have to fill in data in dialogs try to foul the -dialog by providing incomplete or bogus input</li> - <li>Watch for view updating (package explorer, browsing perspective, -outliner) when source content gets changed</li> -</ul> -<ul> - <li>change font for text editor and dialogs to different font</li> - <li>check that dialogs are rendered correctly - <ul> - <li>specified dialog font is used</li> - <li>no buttons and labels clipped</li> - </ul> - </li> -</ul> -<ul> - <li>detached views</li> - <li>dialogs pop up on correct monitor</li> -</ul> -<h2>Platforms</h2> -<table border="1" width="821"> - <tbody> - <tr bgcolor="#cccccc"> - <th colspan="4"> - <div align="center"> <b><font size="+1">Eclipse Reference -Platforms</font></b> </div> - </th> - </tr> - <tr> - <td width="205"><b>Operating system</b></td> - <td width="76"><b>Processor architecture</b></td> - <td width="59"><b>Window system</b></td> - <td width="453"><b>Tester</b></td> - </tr> - <tr> - <td width="205">Microsoft Windows XP</td> - <td width="76">Intel x86</td> - <td width="59">Win32</td> - <td width="453">Jean-Michel Lemieux<br> - </td> - </tr> - <tr> - <td width="205">Red Hat Enterprise Linux WS 3</td> - <td width="76">Intel x86</td> - <td width="59">GTK</td> - <td width="453">Michael Valenta<br> - </td> - </tr> - </tbody> -</table> -<h2>Tests</h2> -<!-- KEEP END --> -<ul> -<li><a href="#00004.html">Repositories View</a> -<ul> -<li><a href="#repoview_basics00001.html">Basics</a> -<ul> -</ul> -<li><a href="#00007.html">Check Out - prompts</a> -<ul> -</ul> -<li><a href="#checkoutwizard00001.html">Check Out Wizard</a> -<ul> -</ul> -<li><a href="#datetags_repoview00001.html">Tags</a> -<ul> -</ul> -</ul> -<li><a href="#00026.html">Sharing</a> -<ul> -<li><a href="#00027.html">Sharing as a subfolder</a> -<ul> -</ul> -<li><a href="#sharingbasics00001.html">Basics</a> -<ul> -</ul> -<li><a href="#00028.html">Reconnecting an existing project</a> -<ul> -</ul> -<li><a href="#00050.html">Sharing a new project</a> -<ul> -</ul> -<li><a href="#project_sets00001.html">Project Sets</a> -<ul> -</ul> -</ul> -<li><a href="#00044.html">Replacing</a> -<ul> -<li><a href="#00045.html">With latest</a> -<ul> -</ul> -<li><a href="#00046.html">With another branch of version</a> -<ul> -</ul> -<li><a href="#00047.html">With file revision</a> -<ul> -</ul> -<li><a href="#update_command00001.html">Updating</a> -<ul> -</ul> -</ul> -<li><a href="#00008.html">Comparing</a> -<ul> -<li><a href="#00009.html">Remote resources</a> -<ul> -</ul> -<li><a href="#00039.html">Compare with another branch or version</a> -<ul> -</ul> -<li><a href="#00040.html">Reverting deleted resources</a> -<ul> -</ul> -<li><a href="#00041.html">File Revisions</a> -<ul> -</ul> -<li><a href="#quickdiff00001.html">Quick Diff</a> -<ul> -</ul> -</ul> -<li><a href="#00010.html">Synchronizing</a> -<ul> -<li><a href="#00048.html">Performing a Synchronize</a> -<ul> -</ul> -<li><a href="#00011.html">Synchronize View</a> -<ul> -</ul> -<li><a href="#00049.html">Decorations</a> -<ul> -</ul> -<li><a href="#commit_stes00001.html">Commit Sets Layout</a> -<ul> -</ul> -<li><a href="#sync00001.html">Scenarios</a> -<ul> -</ul> -</ul> -<li><a href="#00012.html">Merging</a> -<ul> -<li><a href="#00022.html">Performing a Merge</a> -<ul> -</ul> -<li><a href="#00013.html">Synchronize View</a> -<ul> -</ul> -</ul> -<li><a href="#00029.html">Patching</a> -<ul> -<li><a href="#00030.html">Importing a zip over a shared project</a> -<ul> -</ul> -</ul> -<li><a href="#00014.html">Resource History</a> -<ul> -<li><a href="#00018.html">Editor Linking</a> -<ul> -</ul> -<li><a href="#00024.html">Annotate</a> -<ul> -</ul> -</ul> -<li><a href="#00020.html">Concurrency</a> -<ul> -<li><a href="#00021.html">Close and disconnect</a> -<ul> -</ul> -</ul> -<li><a href="#00023.html">Restarting Workbench</a> -<ul> -<li><a href="#00019.html">Crash Recovery</a> -<ul> -</ul> -<li><a href="#00025.html">Synchronize View Settings</a> -<ul> -</ul> -</ul> -<li><a href="#00028a.html">SSH2</a> -<ul> -<li><a href="#00029a.html">Server version compatibiliity</a> -<ul> -</ul> -<li><a href="#00030a.html">Proxies</a> -<ul> -</ul> -<li><a href="#00031.html">Generating keys</a> -<ul> -</ul> -<li><a href="#00032.html">General use</a> -<ul> -</ul> -</ul> -<li><a href="#00033.html">Annotate</a> -<ul> -<li><a href="#00034.html">Show Annotation Action</a> -<ul> -</ul> -</ul> -<li><a href="#00035.html">Label Decorations</a> -<ul> -<li><a href="#00036.html">Enablement at startup</a> -<ul> -</ul> -<li><a href="#00037.html">Customizations</a> -<ul> -</ul> -<li><a href="#00038.html">Decorations in the Synchronize pages</a> -<ul> -</ul> -</ul> -<li><a href="#watch_edit00001.html">Watch/Edit</a> -<ul> -<li><a href="#watch_edit_basic00001.html">Basic scenarios</a> -<ul> -</ul> -<li><a href="#watch_edit_editorsview00001.html">Editors View</a> -<ul> -</ul> -</ul> -<li><a href="#perf00001.html">Performance</a> -<ul> -<li><a href="#perf00002.html">Timings</a> -<ul> -</ul> -<li><a href="#perf00004.html">Resource Data Structures</a> -<ul> -</ul> -<li><a href="#perf00005.html">Looking For Leaks</a> -<ul> -</ul> -<li><a href="#perf00006.html">Team Data Structures</a> -<ul> -</ul> -<li><a href="#perf00007.html">Scalability</a> -<ul> -</ul> -</ul> -<li><a href="#failures00001.html">Failure Cases</a> -<ul> -<li><a href="#connections00001.html">Connections</a> -<ul> -</ul> -<li><a href="#auth_problems00001.html">Authentication Problems</a> -<ul> -</ul> -</ul> -<li><a href="#misc00001.html">Misc</a> -<ul> -<li><a href="#00042.html">CVS Console</a> -<ul> -</ul> -<li><a href="#encoding00001.html">Encoding Support</a> -<ul> -</ul> -<li><a href="#passwords00001.html">Password Management</a> -<ul> -</ul> -<li><a href="#ext_connection_method00001.html">EXT</a> -<ul> -</ul> -</ul> -<li><a href="#validate_edit00001.html">Validate Edit</a> -<ul> -<li><a href="#validate_edit_editing_files00001.html">Editing Files</a> -<ul> -</ul> -<li><a href="#validate_edit_refactoring00001.html">Refactoring</a> -<ul> -</ul> -</ul> -</ul> -<h1>Repositories View</h1> -<a name="repoview_basics00001.html"> -<h2>Basics</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - -<h3>Adding and Discarding Locations</h3> - -<p>You should be able to create a repository location from the toolbar of the view or via the context menu. -Try expanding the location, the HEAD, Versions and Branches categories. Also, -try the failures cases from <a href="connections00001.html">Connections</a>. -Things to try: -<ul> -<li>Create repo locations for different connection types: ext, pserver, extssh. -<li>Expanding project nodes should process the children in the background and the -view should remain responsive while this is happening. When children nodes are added to the -tree the tree shouldn't be too jumpy. -<li>Discard a location and ensure it is removed. Also ensure that discarding is not permitted when -projects in the local workspace are shared with the location. -</ul> -</p> - -<h3>Repository Location Properties</h3> - -View a location's properties page and ensure that information is correct and can be changed. -Ensure that the sharing information for any projects mapped to the location are also changed. - -<h3>Modules</h3> - -<h3>Working with modules</h3> - -<ul> - <li>Expanding HEAD or the Versions category should display the modules defined in the CVSROOT/modules file</li> - <li>Check Out and Checkout As should be availabel on modules and should work as expected</li> - <li>Performing a "Configure Branches and Versions" on the module allows the user to set the autorefresh file and add some tags. - Ensure that the module now appears properly in association with those tags.</li> -</ol> - - - -<a name="00007.html"> -<h2>Check Out - prompts</h2> -<p>Since: 3.0 M5<br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - -<h3>Scenario 1</h3> -<ol> - <li>Select a project in HEAD</li> - <li>Perform a Checkout</li> - <li>Ensure project was checked out properly</li> - <li>Select the same project and choose Checkout As</li> - <li>Use the same name and specify a custom location</li> - <li>Ensure that the user is prompted to overwrite</li> - <li>Ensure OK and Cancel have proper behavior</li> -</ol> - -<h3>Scenario 2</h3> -<ol> - <li>Select a project in HEAD</li> - <li>Perform a Checkout</li> - <li>Ensure project was checked out properly</li> - <li>Delete the project but leave the contents on disk</li> - <li>Perform a Checkout of the same project again</li> - <li>Ensure that the user is prompted to overwrite</li> - <li>Ensure OK and Cancel have proper behavior</li> -</ol> - -<h3>Scenario 3</h3> -<ol> - <li>Select a project in HEAD</li> - <li>Perform a Checkout As</li> - <li>Use the same name and specify a custom location</li> - <li>Ensure project was checked out properly</li> - <li>Delete the project but leave the contents on disk</li> - <li>Perform a Checkout As of the same project to the same location as in step 3</li> - <li>Ensure that the user is prompted to overwrite</li> - <li>Ensure OK and Cancel have proper behavior</li> -</ol> - -<h3>Scenario 4</h3> -<ol> - <li>Select a project in HEAD</li> - <li>Perform a Checkout As</li> - <li>Use the same name and specify a custom location</li> - <li>Ensure project was checked out properly</li> - <li>Delete the project but leave the contents on disk</li> - <li>Perform a Checkout on the project</li> - <li>Ensure project was checked out properly</li> - <li>Perform a Checkout As of the same project to the same location as in step 3</li> - <li>Ensure that the user is prompted twice: once to overwrite project and once to overwrite custom location</li> - <li>Ensure OK and Cancel have proper behavior</li> -</ol> - - -<a name="checkoutwizard00001.html"> - -<h2>Checkout Wizard</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p><body> - -<p>The checkout wizard should be available from the following parts of the workbench: -import, new project, empty workspace CVS synchronize action, toolbar in CVS perspective. -The checkout wiard is also available from the context menu of the repositories view -as the Checkout As menu item.</p> - -<p>The following variants should be tested: -<ul> -<li>Create a new repository location and checkout a project entirely from the wizard. -<li>Check out a tag -<li>Check out a project that does not contain a .project file. This should result in -a second wizard that allows projct configuration (e.g. Java project). -</ul> - -<h3>Repositories View Checkout Variants</h3> -These test require an existing repository which contains projects, at least one of which -does not contain a .project file. -<ol> - <li>Perform "Check Out" on a single project. Ensure that repeating results in overwrite prompt.</li> - <li>Perform "Check Out" on multiple projects.</li> - <li>Perform "Check Out As..." on a single project (that contains a .project file) and enter custom name and/or custom location.</li> - <li>Perform "Check Out As..." on a single remote project that does not have a .project file and - ensure that the user is prompted for the project type to create.</li> - <li>Perform "Check Out As..." on multipe projects and enter a custom parent location.</li> - <li>Perform "Check Out As..." and specify a tag.</li> -</ol> - -<a name="datetags_repoview00001.html"> -<h2>Tags</h2> -<p>Since: 3.0<br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p><body> - -<h3>Refresh Branches and Versions</h3> -<ol> - <li>Select a repository location and perform "Refresh Branches and Versions...". - <li>Select one or more projects that contain a .project file and have been tagged with branch and version tags and click finish.</li> - <li>Expand the respository entry to view ... - <ul> - <li>projects in HEAD,</li> - <li>branches and projects in BRANCHES,</li> - <li>projects and versions in VERSIONS.</li> - </ul> -</ol> - -<h3>Configure Branches and Versions</h3> -<ol> - <li>Select a project in the repositories view and perform "Configure Branches and Versions...". - <li>Select some branch and version tags to be remembered.</li> - <li>Expand the respository entry to view ... - <ul> - <li>projects in HEAD,</li> - <li>branches and projects in BRANCHES,</li> - <li>projects and versions in VERSIONS.</li> - </ul> -</ol> - -<h3>Date Tags</h3> -The ability to create Date tags should be available from the following locations: - -<ul> -<li>Repositories view</li> -<li>Configure Branches and Versions dialog -<li>Tag selection dialogs (Compare with and Replace with Branch or Version) -</ul> - - - -<h1>Sharing</h1> -<a name="00027.html"> -<h2>Sharing as a subfolder</h2> -<p>Since: 3.0 M6<br> -Last Modified: $Date: 2004/02/25 20:34:42 $</p> - -<p>Perform the following steps:</p> -<ol> - <li>Create a new project</li> - <li>Select Team>Share</li> - <li>Select a repository and click next</li> - <li>Enter a path with at least two segments as the remote module name</li> - <li>Click Finish</li> -</ol> -<p>Ensure that the project was shared properly (i.e. remote folders were created). - -<a name="sharingbasics00001.html"> -<h2>Basics</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - -<p>Single select a project and select share.</p> -<ul> -<li>Should only be available if the project is not shared. -<li>Menu item should be available from the Project top level menu. -<li>Wizard should allow you to cancel at any time and un-map the project. Note that some resources may of been committed via the wizard that will remain committed. -<li>Should be able to share as a repository root {".") or a folder at any level (i.e. a folder name with one or more paths). -</ul> - - -<a name="00028.html"> -<h2>Reconnecting an existing project</h2> -<p>Since: 3.0 M6<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> -<p> -The following scenario represents how a user would reconnect a project that does -not contain CVS meta-data to it's remote counterpart. It is assumed that the local project -was derived from a previous version of the remote project but both the local project and -the remote may have been modified since then. -</p> -<h3>Scenario 1: Existing location using project name</h3> -<p>Perform the following steps:</p> -<ol> - <li>Load an existing project (using Checkout or you could import a plug-in project from the target area)</li> - <li>Disconnect the project and indicate that CVS meta-data is to be deleted</li> - <li>Modify some local resources</li> - <li>Optionally, modify the remote contents of some resources using a separate checkout</li> - <li>Perform a Team>Share Project and select CVS (if there is more than one - repository provider available).</li> - <li>Select the repository the project was loaded from and click Next.</li> - <li>Use the project name as the module name. Click Next.</li> - <li>In the tag page, select HEAD as the branch to share with and click Next</li> - <li>In the sharing page, only the files that do not have the same contents - as the server should appear. Perform a Mark as Merged or Commit on these - files. - <li>Click Finish.</li> -</ol> - -<h3>Scenario 1: New location using curstom module name</h3> -<p>Perform the following steps:</p> -<ol> - <li>Load an existing project using Checkout As and a different name</li> - <li>Disconnect the project and indicate that CVS meta-data is to be deleted</li> - <li>Discard the repository location<li> - <li>Modify some local resources</li> - <li>Optionally, modify the remote contents of some resources using a separate checkout</li> - <li>Perform a Team>Share Project and select CVS (if there is more than one - repository provider available).</li> - <li>Select to create a new repository and click Next</li> - <li>Enter the repository information for the repository and click Next</li> - <li>Enter the name of the module that the project was loaded from. Click Next.</li> - <li>In the tag page, select HEAD as the branch to share with and click Next</li> - <li>In the sharing page, only the files that do not have the same contents - as the server should appear. Perform a Mark as Merged or Commit on these - files. - <li>Click Finish.</li> -</ol> - - -<a name="00050.html"> -<h2>Sharing a new project</h2> -<p>Since: 3.0 M8<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<h3>Scenario 1: Existing location using project name</h3> -<p>Perform the following steps:</p> -<ol> - <li>Create a new project that does not exist in the repository</li> - <li>Select Team>Share and select CVS (if there is more than one - repository provider available).</li> - <li>Select a repository and click Next</li> - <li>Use the project name as the module name. Click Next.</li> - <li>After a time, the last page should show the outgoing changes in the project. - Commit the changes from the synchronize pane.</li> - <li>Click Finish</li> -</ol> - -<h3>Scenario 2: New location using different name</h3> -<p>Perform the following steps:</p> -<ol> - <li>Create a new project</li> - <li>Select Team>Share and select CVS (if there is more than one - repository provider available).</li> - <li>Select to create a new repository and click Next</li> - <li>Enter the repository information for a new repository and click Next</li> - <li>Enter a single segment module name that does not exist in the repository and click Next.</li> - <li>After a time, the last page should show the outgoing changes in the project. - Commit the changes from the synchronize pane.</li> - <li>Click Finish</li> -</ol> - -<a name="project_sets00001.html"> -<h2>Project Sets</h2> -<p>Since: 2.1 <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<ul> -<li>Create a project set from a workspace with multiple projects shared with CVS. The shared projects in the workspace should include projects shared with the following: branch, version, date, and HEAD. -<li>Start with an empty workspace and import the projects using the import projects sets wizard. -<li>You should be prompted for a password and username for the locations. -<li>Ensure that the projects are checked out correctly and against the correct tag. -</ul> - - -<h1>Replacing</h1> -<a name="00045.html"> -<h2>With latest</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<p>Ensure that replace srubs the local resources leaving to outgoing changes. And verify the following: -<ul> -<li> -</ul> - - -<a name="00046.html"> -<h2>With another branch of version</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<p>Check the following for all cases of replace: -<ul> -<li>decorators are updated in the navigator/packages view and synchronize view. -<li>if a version is loaded that you can't commit to it -<li>if a branch is loaded, that you can commit to it. -</ul> - - -<a name="00047.html"> -<h2>With file revision</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<ul> -<li>If the file isn't managed the action should no appear. -<li>If the file doesn't have any revisions you should be prompted -<li>If the file has revisions you should be prompted with the list of revisions in a compare dialog -<li>In the compare dialog you can select any revision and compare changes but merging isn't supported -<li>If a revision is selected the Replace button should be enabled. Otherwise it should be disabled -<li>If you selected the replace button the file should contain the contents of the revision selected. The dialog will also close. -<li>Ensure that the titles are ok (e.g. dialog title, structure pane title...) -</ul> - - -<a name="update_command00001.html"> -<h2>Updating</h2> -<p>Since: 2.0 <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<p>You can run an update and open the console to see the files that are being updated.</p> -<p>You can run the update and switch to another branch, this should keep your outgoing changes and update all other non-changed files.</p> - - -<h1>Comparing</h1> -<a name="00009.html"> -<h2>Remote resources</h2> -<p>Since: 3.0 M5<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> -<h4>Compare With... in Repositories view </h4> -<p>Perform the following steps:</p> -<ol> - <li>Select a project in HEAD and choose Compare With... from context menu</li> - <li>Select a branch tag</li> - <li>Ensure result of comparison is correct</li> - <li>Repeat and in step 2) use a version tag</li> -</ol> -<p>Repeat the above steps for a project in a branch and a project version.</p> -<p>Repeat the above steps for a selected folder and a selected file.</p> -<h4>Compare on two selections in Repositories view</h4> -<p>Perform the following steps:</p> -<ol> - <li>Select a project in HEAD</li> - <li>CTRL-select a project in a branch</li> - <li>Choose Compare from context menu</li> - <li>Ensure result of comparison is correct</li> -</ol> -<p>Repeat the above for various conbinations (branch + version, version + branch, - branch + branch, version + version).</p> - <p>Repeat the above steps for a selected folder and a selected file.</p> -<h4>Compare on two selections in Resource History view.</h4> -<p>Perform the following steps:</p> -<ul> - <li>Open Resource History view on a file with multiple revisions</li> - <li>Select 2 and choose Compare from the context menu</li> - <li>Ensure result of comparison is correct</li> -</ul> - - -<a name="00039.html"> -<h2>Compare with another branch or version</h2> -<p>Since: M8<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> -<p> -You should be able to select a project/folder/resource and compare againts -another branch or version. Multi-select should work across projects in -different repositories. Once the comparison is shown it should be possible to -merge changes into the local workspace. It should also be possible to remember -the comparison, which will cause it to appear in the synchronize view.</p> -<p> -We should support multi-selection of files, but I'm not sure what should be -shown to the user in those cases.</p> -<h3>On file selected</h3> -<ul> -<li>If the file has differences open a compare editor and show otherwise a message is shown to indicate that the file is the same. -<li>should be able to open the history view and link in to the opened compare editor -<li>the compare editor should update when changes are made to the local file in some other context (e.g other editor, refactoring). -</ul> - -<h3>Multiple selection</h3> -<p>Entire contents of the folder are compared deep. If changes are found the user is notified and they are -shown in a dialog. If no changes are found the user is notified. The dialog should allow the user to browse -the changes and merge anything into his workspace. If the user wants to keep the comparison non-model, he -can add it to the synchronize view. There is a button to do so on the compare dialog.</p> - -<h3>Merging changes</h3> -<p> -When the compare dialog is showing several changes you should be able to selectively merge anything into the local workspace. Specific attention should -be made to the following cases: -</p> -<ul> -<li>Edit the local then press ok. You should be prompted to save the changes and the changes should be correctly updated in the corresponding resource. -<li>Edit the local and browse to another file. You should be prompted to save the changes. -<li>Press the cancel button with changes, you should be prompted. -</ul> - -<a name="00040.html"> -<h2>Reverting deleted resources</h2> -<p>Since: M8<br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - -You should be able to restore a deleted revision from the CVS server Team>Restore from Repository - - -<a name="quickdiff00001.html"> - -<h2>Quick Diff</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<p>Enable CVS quick diff for text and java files via the Workbench > Editors > QuickDiff preference. Then try the following -scenarios.</p> - -<ol> - -<li>Open a file and make changes to it. You will see the quickdiff annotations -marking the changes. Next, run Team > Replace with latest. The annotations are -removed and the file is clean. - -<li>same as 1 but this time instead commit the file. The quickdiff annotations -are removed and the file is clean. - -<li>checkout two copies of the same project. Open file1 from both projects. Make -changes to file1 in project1 and commit the change. Synchronize project2 and -file1 from project1 will show the quickdiff annotations for the new incoming -changes. - -<li> same as previous but this time actually update the file. The files quickdiff -annotations are removed and the file is clean. -</ol> - - -<h1>Synchronizing</h1> -<a name="00048.html"> -<h2>Performing a Synchronize</h2> -<p>Since: M8<br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - -<p> -Synchronizing means to compare your local workspace contents with the contents -in another location with the goal that the two locations should contain the -same contents at some point. -</p> - -<h3>Performing a Synchronize operation</h3> -<p> -There are a few ways of launching a synchronize operation. They all open the same dialog but the initial -selection is affected by where the operation is launched. Here is the list of ways to start a -synchronize along with the expected initial selection. -<ul> -<li><b>Using the global synchronize action (via toolbar or keybinding)</b>: The -selection should be obtained from the active view. If no view is active, all -prjects should be selected. -<li><b>Using the Synchronize button in toolbar of the Synchronize view</b>: -All projects should be selected. -<li><b>Selecting Synchronize from the context menu of resources in the synchronize view</b>: -The selection should match what was selected when the menu was selected. -<li><b>Selecting Team > Synchronize with Repository from the context menu of any resource based view</b>: -The selection should match what was selected when the menu was selected. -</ul> -</p> -<p> -Once launched, a synchronize will run in the background. Currently, the user is prompted to -switch perspectives when the synchronize is launched. When a synchronize completes, the user is prompted either with a dialog stating there is no changes -or one that contains a details area that shows the incoming changes. The user -is given the option to supress the post-synchronize dialog. - -<h3>Notice a file is out-of-sync in another view (e.g. packages explorer, types) and want to see the changes</h3> -<p>In case you can select a file, it will be refreshed with the server, and if changes are found the compare editor is opened -that will allow browsing the changes. If no changes are found, you will be prompted.</p> - -<h3>From another view would like to browse the outgoing/incoming changes for several resources</h3> -<p>Select a folder or group of files and Team > Synchronize will open the sync view and automatically refresh with -the remote repository.</p> - -<h3>In the sync view and would like to refresh to see if there are new changes from the server</h3> -<p> - -</p> - -Assumption, the sync view may or may not be open when the synchronize is performed. Maybe we need a different prompt -each case. One for Team > Sync and another for refresh from the sync view. - - -<a name="00011.html"> -<h2>Synchronize View</h2> -<p>Since: 3.0 M5<br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - -<h3>Synchronize View Modes</h3> - -Ensure that choosing modes -<ul> -<li>result in proper filtering -<li>updates status bar properly -</ul> - -<h3>Synchronize View Operations</h3> -<p>Ensure Commit and Update buttons:</p> -<ul> - <li>operate on all applicable visible changes</li> - <li>exclude filtered changes</li> - <li>exclude conflicts</li> -</ul> -<p>Ensure Update menu action:</p> -<ul> - <li>is enabled when selection contains incoming or conflicting changes</li> - <li>operates only on selected changes</li> - <li>silently handles mergable conflicts</li> - <li>will prompt if conflicts are no mergable</li> -</ul> -<p>Ensure Commit menu action</p> -<ul> - <li>is enable only when selection contains outgoing changes</li> - <li>prompts form unadded resources</li> - <li>operates only on selected changes</li> -</ul> -<p>Ensure Override and Commit and Override and Update</p> -<ul> - <li>are only enabled for conflicts or changes in the opposite direction</li> - <li>operates only on selected changes</li> -</ul> -<p>Ensure Refresh button refreshes all projects regardless of mode, selection - or working set.</p> -<p>Ensure Refresh menu action refreshes only the selection</p> -<h4>Modes and Working Sets</h4> -<p>Ensure that choosing modes and working sets </p> -<ul> - <li>result in proper filtering</li> - <li>updates status bar properly</li> -</ul> -<p>All actions on large sets (Mark as Merged as well)</p> - -The following table can be used to determine what operations are appropriate and what result to expect. - -<table height="124" border="1" width="99%"> - <tbody> - <tr> - <td width="25%"><b>Change Type</b></td> - <td width="25%"><b>Action</b></td> - <td width="50%"><b>Result</b></td> - </tr> - <tr> - <td width="25%"><b>Incoming File Change</b></td> - <td width="25%">Update</td> - <td width="50%">Remote contents become local. Try with both Text and - Binary files.</td> - </tr> - <tr> - <td width="25%"><b>Incoming File Change</b></td> - <td width="25%">Override and Commit</td> - <td width="50%">Only in Both mode. Prompt for release comment. Cancel - aborts, OK commits local file to server.</td> - </tr> - <tr> - <td width="25%"><b>Incoming File Addition</b></td> - <td width="25%">Update</td> - <td width="50%">Remote contents become local. Try with both Text and - Binary files.</td> - </tr> - <tr> - <td width="25%"><b>Incoming File Addition</b></td> - <td width="25%">Override and Commit</td> - <td width="50%">Only in Both mode. Prompt for release comment. Cancel - aborts, OK commits deletion to server.</td> - </tr> - <tr> - <td width="25%"><b>Incoming File Deletion</b></td> - <td width="25%">Update</td> - <td width="50%">Local file is deleted.</td> - </tr> - <tr> - <td width="25%"><b>Incoming File Deletion</b></td> - <td width="25%">Override and Commit</td> - <td width="50%">Only in Both mode. Prompt for release comment. Cancel - aborts, OK commits local file to server.</td> - </tr> - <tr> - <td width="25%"><b>Outgoing File Change</b></td> - <td width="25%">Commit</td> - <td width="50%">Prompt for release comment. Cancel aborts, OK commits - local file to server.</td> - </tr> - <tr> - <td width="25%"><b>Outgoing File Change</b></td> - <td width="25%">Override and Update</td> - <td width="50%">Only in Both mode. Remote contents become local. Try - with both Text and Binary files.</td> - </tr> - <tr> - <td width="25%"><b>Outgoing File Addition</b></td> - <td width="25%">Add to Version Control</td> - <td width="50%">Adds the file to version control. The icon should change - in the sync view, and Commit should now be enabled.</td> - </tr> - <tr> - <td width="25%"><b>Outgoing File Addition</b></td> - <td width="25%">Add to .cvsignore</td> - <td width="50%">Adds the file to .cvsignore. The file should disappear - from the sync view. The .cvsignore file should appear (if it wasn't visible - already). The file should not appear in subsequent syncs.</td> - </tr> - <tr> - <td width="25%"><b>Outgoing File Addition</b></td> - <td width="25%">Commit</td> - <td width="50%">Commit is only enabled on an outgoing addition if it - has first been added to version control. Prompt for release comment. Cancel - aborts, OK commits local file to server.</td> - </tr> - <tr> - <td width="25%"><b>Outgoing File Addition</b></td> - <td width="25%">Override and Update</td> - <td width="50%">Only in Both mode. Local file is deleted.</td> - </tr> - <tr> - <td width="25%"><b>Outgoing File Deletion</b></td> - <td width="25%">Commit</td> - <td width="50%">Prompt for release comment. Cancel aborts, OK commits - deletion to server.</td> - </tr> - <tr> - <td width="25%"><b>Outgoing File Deletion</b></td> - <td width="25%">Override and Update</td> - <td width="50%">Only in Both mode. File is re-created, remote contents - become local.</td> - </tr> - <tr> - <td width="25%"><b>Conflicting File Change</b></td> - <td width="25%">Override and Commit</td> - <td width="50%">Prompt for release comment. Cancel aborts, OK commits - local file to server. Applies to both auto-mergeable and non-mergeable conflicts.</td> - </tr> - <tr> - <td width="25%"><b>Auto-mergeable Conflicting File Change</b></td> - <td width="25%">Override and Update</td> - <td width="50%">Auto-mergeable conflicts have a two-way red/green arrow. - Dialog prompts user to either auto-merge or replace. If user chooses auto-merge, - then remote changes are merged in with local changes. File should still -be dirty, local changes should still be present, CVS markup should not be -present, and no .# files should have been created. If user chooses replace, -then local changes are discarded and remote contents replace local. No .# -files created, no CVS markup, and the file is not dirty as a result. If -the user chooses cancel nothing happens.</td> - </tr> - <tr> - <td width="25%"><b>Non-mergeable Conflicting File Change</b></td> - <td width="25%">Override and Update</td> - <td width="50%">Dialog prompts user to replace local changes. If user - cancels nothing happens. If user chooses OK, then local changes are discarded - and remote contents replace local. No .# files created, no CVS markup, and - the file is not dirty as a result.</td> - </tr> - <tr> - <td width="25%"><b>Conflicting File Addition</b></td> - <td width="25%">Add to Version Control</td> - <td width="50%">Adds the file to version control. The icon should change - in the sync view, and Override and Commit should now be enabled.</td> - </tr> - <tr> - <td width="25%"><b>Conflicting File Addition</b></td> - <td width="25%">Override and Commit</td> - <td width="50%">Override and Commit is only enabled on an outgoing addition -if it has first been added to version control. Prompt to warn of conflicting -changes. If OK, prompt for release comment. Cancel aborts either dialog. -OK commits local file to server.</td> - </tr> - <tr> - <td width="25%"><b>Conflicting File Addition</b></td> - <td width="25%">Override and Update</td> - <td width="50%">Remote contents become local.</td> - </tr> - </tbody> -</table> - - -<a name="00049.html"> -<h2>Decorations</h2> -<p>Since: M8<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -There are many standard decorations in the sync view. Most significant are the propagated flags. - -<h3>Conflicts</h3> -<p> -Conflicting changes should be propagated to parent resources such that you can easily see, when the tree -is collapsed that there are conflicts. When the conflict is resolved, the parent conflict markers should be -removed. -</p> -<h3>Error and Warning problem markers</h3> -<p> -Error and warning makers are shown on resources and propagated to parent resources such that you can -easily see if you are releasing errors or warnings. -</p> -<h3>Branch changes</h3> -<p> -Changes to branches, revisions, should be updated automatically in the views decorators. For example, if you branch -from the sync view the branch name should appear. -</p> - - -<a name="commit_stes00001.html"> -<h2>Commit Sets Layout</h2> -<p>Since: 3.0 M9<br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - - - -<a name="sync00001.html"> -<h2>Scenarios</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - -<h3>Making Manual Changes</h3> -<p>Create a conflicting file change. Manually edit the left source pane in - the sync view. Hit "Save" on the popup menu. The file should remain a Conflict. Choose - Mark as Merged in the popup menu of the tree. The file should change to -an outgoing change. Commit the outgoing change.</p> -<h3>Merging Conflicts</h3> -<p>Try Override and Update with different combinations of Auto-Mergeable -and Non-Mergeable conflicts in the selection. If all conflicts are Non-Mergeable, - then the only choice is to replace with remote or cancel. If one or more -conflicts are Auto-Mergeable, the choices are (a) Auto-Merge any applicable -files, and replace the rest with remote, (b) Replace all files with remote -or (c) Cancel.</p> -<h3>Removing from View</h3> -<p>Choose Remove from View. Selected nodes should disappear. Refresh the -view. The nodes should reappear.</p> - -<h3>Working with Branches</h3> -<p>Try any and all of the above, but use a branch instead of HEAD. Behaviour - should be identical. The sync view decorator should show you the name of -the branch.</p> -<h3>Using Mixed Tags</h3> -<p>Using Team->Branch, Replace With->Branch or Version, and Team->Tag - as Version, you can create a project which has different tags mixed into -it. For example, one folder may be shared as V2_0, a single file may be attached - to the branch NEW_FEATURE_BRANCH, and the root of the project may be attached - to HEAD. We need to test usage of these projects in the sync view. For example, - if developer 1 has project P shared with HEAD, and folder P/F is shared -with branch B, have developer 2 release a change to folder F in HEAD, and -have developer 1 perform a sync. In this case developer 1 should not see -the incoming change.</p> - - -<h1>Merging</h1> -<a name="00022.html"> -<h2>Performing a Merge</h2> -<p>Since: M8<br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> - - -<h3>Scenario 1: One Time Merge</h3> - -<p> -Using Team>Merge, merge the changes from a branch into HEAD. Once completed, in the synchronize view, -update the incoming changes, resolve any conflicts and ensure they worked, After updating, -redo the same merge. A no-changes dialog should be -presented since the local contents match the end-point. - -<h3>Scenario 2: Ongoing Merge</h3> - -After performing a one-time merge, pin the entry in the synchronize view. -Release changes to the end point (branch) and synchronize the merge. -The new changes should appear in the synchronize view. Update to these -changes as appropriate. - -<h3>Removing a Merge</h3> - -<p>Delete the merge from the synchronize view using the remove toolbar button. The merge subscriber should be removed from the view. - - -<a name="00013.html"> -<h2>Synchronize View</h2> -<p>Since: 3.0 M5<br> -Last Modified: $Date: 2004/06/01 19:14:48 $</p> -<ul> -<li>Same scenarios as <a href="00011.html">CVS Synchronize View</a> except you can't commit. -<li>Test mark as merged (ensure that it can work on large data sets) -</ul> - -<h1>Patching</h1> -<a name="00030.html"> -<h2>Importing a zip over a shared project</h2> -<p>Since: 3.0 M6<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<p>This scenario captures one means of patching. It assumes that a zip file contains -a previous version of a project that has been modified in some way and added to -a zip archive (without CVS directories).</p> - -<p>Perform the following steps:</p> -<ol> - <li>Load the project from CVS (using Checkout or some other means)</li> - <li>Import the zip over the loaded project.</li> - <li>Ensure that the sync states are Outgoing for all resources from the zip file.</li> - <li>Ensure that all folders from the zip file (except new ones) - are marked as in-sync and all files (except new ones) are outgoing changes. - <li>Changing the comparison criteria to compare contents should not contact the server - and should leave only the resources that differ in the sync view. Perform a - Mark As Merged and a Commit on these resources.</li> - <li>Changing the comparison criteria back to revision number will reveal all the files - whose content did not change, perform a Mark as merged on these resources followed by - a Team>Update on the project in the Navigator (Note: This could be handled better).</li> - <li>After the update, ensure the project has no out-of-sync resources.</li> -</ol> - - -<h1>Resource History</h1> -<a name="00018.html"> -<h2>Editor Linking</h2> -<p>Since: 3.0 M5<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<ol> - <li>Open the Resource History view and enable editor linking</li> - <li>Open a compare editor from the sync view (on a resource that exists remotely) - and ensure that the history view updates.</li> - <li>Open an editor from the Repositories vew and ensure that the history view - updates.</li> - <li>Open an editoron a local file and ensure that the history view updates.</li> -</ol> -<p>Repeat the above with the Resource History view hidden and ensure that no revision - history is fetched (i.e. no jobs appear in progress view).</p> - - -<a name="00024.html"> -<h2>Annotate</h2> -<p>Since: 3.0 M6<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<h4>Annotate action should be available from</h4> -<ul> -<li>history view, repo explorer, resource/packages view -</ul> - -<h4>Annotate java files</h4> -<ul> -<li>should show the java editor -<li>you should be able to step through changes in the annotate view and the java editor should -stay in sync (e.g. highlight) the changes associated with the selected change in the annotate view. -<li>you should also be able to select a line in the java file and the annotate view should -select the change that is associated with that line. -<li>the history view should show the history for the opened file and highlight the revision -of the currently selected change in the annotate view. -</ul> - -<h4>Annotate non-text editor files</h4> -<ul> -<li>annotate plugin.xml file -<li>the default text editor should be shown -<li>you should also be able to select a line in the text file and the annotate view should -select the change that is associated with that line. -<li>the history view should show the history for the opened file and highlight the revision -of the currently selected change in the annotate view. -</ul> - -<h4>Annotate binary files</h4> -<ul> -<li>annotate a file marked as binary -<li>the server should report an error that annotations cannot be shown for binary files. -</ul> - - -<h1>Concurrency</h1> -<a name="00021.html"> -<h2>Close and disconnect</h2> -<p>Since: 3.0 M5<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<h4>Background refresh and disconnect</h4> -<ol> - <li>Load several projects from the repository</li> - <li>Ensure that several have outgoing and incoming changes</li> - <li>Choose one project to disconnect. The project should have incoming and outgoing - changes and be one of the later ones in the refresh order (alphebetical).</li> - <li>Perform a refresh on all the projects</li> - <li>While the refresh is occuring, disconnect the project chosen in step 3) - and leave CVS folders.</li> - <li>Ensure that the project is removed from the sync view and no errors occur</li> -</ol> -<p>Repeat the steps and purge the CVS meta-data in step 5).</p> -<p>Repeat the above steps but change the operation in step 5) to the following:</p> -<ul> - <li>close project</li> - <li>project where server is unreachable</li> - <li>delete project</li> - <li>binary project import over source project with outgoing changes</li> -</ul> -<h4>Decoration and disconnect</h4> -<ul> - <li>Load several projects from the repository</li> - <li>Ensure that several have outgoing and incoming changes</li> - <li>Choose one project to disconnect. The project should have incoming and outgoing - changes and be one of the later ones in the refresh order (alphebetical).</li> - <li>Turn on CVS decorators</li> - <li>As the decorations are being calculated, disconnect all projects from CVS - control.</li> - <li>Ensure that the project is removed from the sync view and no errors occur</li> -</ul> -<p>Repeat the above steps but change the operation in step 5) to the following:</p> -<ul> - <li>close project</li> - <li>project where server is unreachable</li> - <li>delete project</li> - <li>binary project import over source project with outgoing changes</li> - <li>delete or move files and folders (to test move/delete hook)</li> -</ul> - - - -<h1>Restarting Workbench</h1> -<a name="00019.html"> -<h2>Crash Recovery</h2> -<p>Since: 3.0 M5<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<p>Scenario 1</p> -<ol> - <li>Turn on deep dirty decoration</li> - <li>Dirty a file and ensure that the file and it's parents are dirty</li> - <li>Quit Eclipse so dirty state is persisted</li> - <li>Restart and perform an override and update or commit and ensure file and - parents are clean</li> - <li>Kill Eclipse</li> - <li>Restart and ensure parents and file are clean</li> -</ol> -<p>Scenario 2</p> -<ol> - <li>Check out two copies of the same project</li> - <li>Dirty the same file in both projects, commit one and refresh the other in - the sync view so a conflict is visible</li> - <li>Quit Eclipse so that the sync state is persisted</li> - <li>Restart Eclipse and perform an Override and Commit on the conflict</li> - <li>Kill Eclipse</li> - <li>Restart Eclipse and ensure that the sync view doesn't show the file (i.e - the file is in-sync).</li> -</ol> - - -<a name="00025.html"> -<h2>Synchronize View Settings</h2> -<p>Since: 3.0 M6<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<h4>Saved between sessions</h4> -<p>The following GUI preferences in the Synchronize View are persisted between workbench -sessions. Also they are persisted for each participant. You should be able to create -a merge and workspace participant, then change the settings on each. Restart Eclipse and the settings -should be maintained for each participant. The persisted settings are:</p> -<ul> -<li>mode -<li>layout -<li>working set -</ul> - -<h1>SSH2</h1> -<a name="00029a.html"> -<h2>Server version compatibiliity</h2> -<p>Since: M6<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -This test is to ensure that the ssh2 connection method properly delagates to ssh1 -when the server only supports ssh1. - - -<a name="00030a.html"> -<h2>Proxies</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -Using HTTP and SOCKS5 proxies. - - -<a name="00031.html"> -<h2>Key Generation</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -You should be able to generate private/public keys in the SSH2 preference -page. Here are some scenarios for testing: -<ul> -<li>Generate keys and save private key without password. You should be prompted. -<li>Generate keys and save private key with password. You shouldn't be prompted. -<li>Generate keys and install using the sftp button. -</ul> - -<a name="00032.html"> -<h2>General use</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -This tests the prompting and usage of the SSH2 connection method: -<ul> -<li>Delete all files in your SSH_HOME directory. You can find this directory by opening the SSH2 preference page -<li>Create a CVS repository connection of type 'extssh'. You will be prompting about the server id not being in -your known_hosts file. -<li>Select cancel, and error should be shown indicating that the location was not validated do you want to keep it. -</ul> - -<h1>Annotate</h1> -<a name="00034.html"> -<h2>Show Annotation Action</h2> -<p>Since: 3.0 M3<br> -Last Modified: $Date: 2004/06/02 18:01:36 $</p> - -<p>Annotate a non-managed file, binary file, plugin.xml file... Be creative.</p> -<p>Ensure that the annotate view, editor, and history view stay synched.</p> - - -<h1>Label Decorations</h1> -<a name="00036.html"> -<h2>Enablement at startup</h2> -<p>Since: 3.0 M7<br> -Last Modified: $Date: 2004/06/02 18:01:36 $</p> - -<p>The CVS decorators should not be enabled at start-up. Verify the label decorator preference page.</p> -<p>When sharing or checking out a project, the decorators will be enabled automatically.</p> -<p>Disabling after they have been enabled and restarting. The decorators should be disabled. Checkout should not enable them again.</p> -<p>Enable the decorations again, then disconnecting a project should clear the decorators on the project.</p> - -<a name="00037.html"> -<h2>Customizations</h2> -<p>Since: 2.0 <br> -Last Modified: $Date: 2004/06/02 18:01:36 $</p> - -<p>You should be able to customize the label decorations via the preference page. The customizations will -take effect when apply is pressed. Resetting the defaults should work. - -</p> - - -<a name="00038.html"> -<h2>Decorations in the Synchronize pages</h2> -<p>Since: 3.0 M8<br> -Last Modified: $Date: 2004/06/02 18:01:36 $</p> -<p> -CVS text label decorations should be visible in the CVS synchronize participants. We don't bother to show -the images because the sync view already shows the state images. The labels should also update if the -'show change in label' preference is changed. -</p> -<p> -Also, in the CVS synchronize view the revisions shown are the <local> - <remote>. So ensure that the correct -remote is shown.</p> -<p> -Ensure that when the local tag changes the decorators in the sync view and navigator get updated.</p> -<p>Ensure that there is no flicker in packages view when cvs decorator updated on commit, update.</p> - -<h1>Watch/Edit</h1> -<a name="watch_edit_basic00001.html"> -<h2>Basic scenarios</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/02 16:07:33 $</p> - -<p>To setup, goto the CVS preference page and enable watch edit for all projects checked out from CVS. And then set the prompt option to always prompt.</p> -<ol> -<li>Check out a project from CVS and verify that the files are marked as read-only. -<li>Open a file and edit it. You should be prompted to edit it. Say yes. There should be a brief pause, then you can edit the file. -<li>Open another file and start editing it. You should be prompted to edit it. Say no. The file will remain read-only and you won't be allowed to edit it. -<li>Open a file and edit it. Say yes to the prompt. commit the file and edit again. You should be prompted a second time. -<li>Open a file and edit it. Say yes to the prompt. Replace the file from the repository and edit again. You should be prompted to edit again. -<li>Open a file and edit it. Un-plug your network connection. Say yes to the prompt to send a notification. There should be a pause, then the file should be editable. -<li>Checkout another copy of the project. Edit a file, then try to edit the same file in the another project copy. You should be notified that the file is currently being edited by someone else. -</ol> - -<p>Saving files - setup is the same as previous</p> -<ol> -<li>Check out a project from CVS and verify that the files are marked as read-only. -<li>Open a file and edit it. You should be prompted to edit it. Say yes. There should be a brief pause, then you can edit the file. -<li>Edit the file but don't save it. -<li>Edit the file in a system editor outside of Eclipse, then in the resource navigator, commit the file. The resource's decorator will change. Ignore all the prompts -about saving the un-saved file. -<li>Return to the unsaved editor and try typing. You should be prompted to call validate edit again. -</ol> - -<p>validateEdit fails</p> -<ol> -<li>Check out a project from CVS and verify that the files are marked as read-only. -<li>Disconnect from network so that the validateEdit would fail. -<li>Open a file and edit it. You should be prompted to edit it. Say yes. There should be a pause then the error should be reported in the -editor pane showing the exception that occured. -</ol> - -<p>Refactoring</p> -<ol> -<li>Check out a project from CVS and verify that the files are marked as read-only. -</ol> - - -<a name="watch_edit_editorsview00001.html"> -<h2>Editors View</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 20:28:37 $</p> -<p>Test that you can properly show the editors on a file.</p> - -<h1>Performance</h1> -<a name="perf00002.html"> -<h2>Timings</h2> -<p>Since: 3.0<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -This section contains various timing results and comparisons. - -<h3>Overview</h3> - -The purpose of this section is to provide a small set of tests that can -be used to benchmark the Eclipse CVS client. The areas tested are: - -<ol> -<li>Checkout -<li>Synchronizing -<li>Updating -</ol> - -<h3>Setup</h3> - -The following should be considered when obtaining timings: - -<ul> -<li>The Progress view in verbose mode can add 20% or more to times. -In regular mode, it can still add a bit to the time. For these timings, -the view was open but hidden. -<li>The Console view can add as much as 20% to times. For these tests, -the console was turned off entirely. -<li>Running an eclipse operation several times will "warm-up" the code path -due to JIT. The timings for Eclipse were usually the secodn or third -timing obtained. -</ul> - -The following numbers were obtained on a 2.8GHz PC running GTK, Sun 14.2 -with autobuild off and operations run in the forground. The project used was -org.eclipse.jdt.tests.refactoring. It has a large number of folders and files -which give interesting times. The date the timings were obtained were May 31st, 2004 -so similar numbers can be obtained for comparison using the project snapshot at that time -(which can be obtained using a Date tag). - -<h3>Checkout</h3> - -Checkout of org.eclipse.jdt.tests.refactoring as of 2004/05/31. The timings are -in "mm:ss" and were obtained by obervation (i.e. stopwatch). - -<ul> -<li>Eclipse 3.0 over pserver: 3:00 to 3:30 (several timings) -<ul> -<li>Timings increased slightly with progress view visible and considerably -with progress view in verbose mode. -</ul> -<li>CLI over pserver: 3:00 (1 timing) -</ul> - -<h3>Synchronize</h3> - -Synchronizing of org.eclipse.jdt.tests.refactoring as of 2004/05/31. The timings are -in "mm:ss" and were obtained by obervation (i.e. stopwatch). - -<h4>Synchronize with no changes</h4> - -<ul> -<li>Eclipse 3.0 over pserver: 0:45 -<li>CLI over pserver: 0:42 ("cvs -n update") -</ul> - -<h4>Synchronize with all outgoing, no incoming</h4> - -<ul> -<li>Eclipse 3.0 over pserver: 1:00 -<li>CLI over pserver: 2:20 ("cvs -n update") -</ul> - -<h4>Synchronize with incoming changes</h4> - -Incoming changes were simulated by loading version v20040106 and -then removing the tag (using a special utility action). This resulted -in 393 incoming changes. - -<ul> -<li>Eclipse 3.0 over pserver: 0:55 -<li>CLI over pserver: 0:45 ("cvs -n update") -</ul> - -The timing for Eclipse also includes the status command to fetch the revisions for the 393 incoming changes. - -<h3>Update</h3> - -These timings were obtained using Team>Update for Eclipse and "cvs update ." for the CLI. - -<h4>Update with no changes</h4> - -<ul> -<li>Eclipse 3.0 over pserver: 1:15, 1:25 (2 timings) -<li>CLI over pserver: 1:15 ("cvs update") -</ul> - -<h4>Update with all false outgoing changes (using touch) </h4> - -<ul> -<li>Eclipse 3.0 over pserver: 2:20 -<li>CLI over pserver: 2:20 -</ul> - -<h4>Update with incoming changes</h4> - -Incoming changes were simulated by loading version v20040106 and -then removing the tag (using a special utility action). This resulted -in 393 incoming changes. - -<ul> -<li>Eclipse 3.0 over pserver: 1:55 -<li>CLI over pserver: 1:55 ("cvs -n update") -</ul> - - -<a name="perf00004.html"> -<h2>Resource Data Structures</h2> -<p>Since: 3.0<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -This section contains results on memory footprint of CVS in the Core resource -plugin data structures. More specifically, CVS uses the session and persistant property -caches along with the synchronizer. - -<h3>CVS Workspace Sync info caches</h3> - -Checking of the cahce usage requires the use of the Core spy tools. To -obtain the memory footprint, perform the following steps. - -<ol> -<li>Install the Core Spy Tools -<li>Launch Eclipse -<li>Checkout several projects -<li>Open the Element Tree Spy to get the memory footprint. At the -time of writting, CVS is the main user of these structures. In future -test, ensure that others are not contributing to the tally. -<li>Disconnect all the projects -<li>The Element Tree Spy memory footprint should be reduced accordingly -</ol> - -The following snapshot of the resource element tree was taken after checking out all of the projects -(294 as of 2004/05/31) in dev.eclipse.org. - -<pre> -Total resource count: 89,466 - Team private: 10,186 - Phantom: 4,055 - Markers: 0 - SyncInfo: 10,432 -Number of layers: 15 -Number of nodes: 89,514 -Number of non-identical strings: 48,456 -Total memory used by nodes: 23,141,343 - Nodes and ResourceInfo: 8,586,108 - Strings: 3,584,724 - Markers: 0 - Sync info: 1,447,861 - Session properties: 9,522,650 - class [B: 2,618,076 - class [Ljava.lang.Object;: 2,564,448 - class org.eclipse.core.internal.utils.ObjectMap: 1,700,240 - class [C: 1,454,994 - class java.lang.Long: 610,800 - class java.lang.String: 286,580 - class org.eclipse.team.internal.ccvs.core.syncinfo.FolderSyncInfo: 285,292 - class java.util.ArrayList: 768 - class org.eclipse.team.internal.ccvs.core.util.StringMatcher: 660 - class org.eclipse.team.internal.ccvs.core.util.FileNameMatcher: 320 - class [Ljava.lang.String;: 300 - class org.eclipse.core.runtime.QualifiedName: 160 - class java.lang.Object: 12 -The top 20 equal but non-identical strings are: - A.java->2,002 - in->1,219 - plugin.xml->913 - out->794 - A_out.java->489 - A_in.java->487 - eclipse->431 - org->421 - Test.java->412 - B.java->345 - build.properties->297 - I.java->269 - internal->256 - about.html->253 - plugin.properties->243 - .cvsignore->227 - .classpath->209 - ui->185 - src->184 - package.html->165 -</pre> - -<h3>CVS Merge memory usage</h3> -Merging in CVS makes use of the Core synchronizer. Perform the following steps -with the Core Spy Tool installed to -ensure proper memory management. - -<ol> -<li>Checkout one or more projects -<li>Open the Element Tree Spy to get the memory footprint. -<li>Perform a merge -<li>Open the Element Tree Spy to get the memory footprint. The only increase -should be in the synchronizer. -<li>Remove the merge from the sync view -<li>The Element Tree Spy memory footprint should be reduced accordingly -</ol> - -<a name="perf00005.html"> -<h2>Looking For Leaks</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<h3>Removing synchronize view entries</h3> - -<ol> -<li>Start with an empty synchronize view -<li>Create an entry in the Synchronize view for each of the following cases: - <ul> - <li>Team>Synchronize - <li>Compare with>Branch or Version - <li>Team>Merge - </ul> -<li>Open the context menu -<li>Select all mode and layout combinations -<li>Remove the entry (making the sync view empty). -<li>Select an item in another view -<li>Using a memory profiler, look for instances of the following classes: - <ul> - <li>ISynchronizeParticipant - <li>SynchronizeModelElement - <li>SyncInfo/SyncInfoSet - </ul> -</ol> - -<h3>Closing the Synchronize view</h3> - -Close all instances of the Synchronize view and ensure that no instances -of ISynchronizeView remain. - - -<a name="perf00006.html"> -<h2>Team Data Structures</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -The Team component provides several data strucutures that can be used to -cache resource synchronization state and resource variants for improved -performance. The plan is to provide tools to interogate these caches in the 3.1 timeframe. - -These caches include: - -<ul> -<li>Resource Variant cache -<li>SubsciberParticipant/SyncInfoSet -</ul> - -<h3>CVS Specific data structures</h3> - -CVS uses several caches to improve performance. Tools should be provided to query the -size of these caches as well. - -<ul> -<li>Console (caches contents while not visible) -<li>Resource History View log entry cache -<li>Commit Sets log entry cache -</ul> - - -<a name="perf00007.html"> -<h2>Scalability</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/04 19:44:24 $</p> - -The following scenario can be used to test a large number of incoming additions. - -<ol> -<li>load org.eclipse.jdt.core.tests.model from dev.eclipse.org -<li>Disconnect Formatter folder and delete it -<li>Synchronize and the contents show up as incoming additions -<li>Peform an Update in the project in the sync view. -</ol> - - -<h1>Failure Cases</h1> -<a name="connections00001.html"> -<h2>Connections</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 20:28:37 $</p> - -<p>Test that authentication, connection errors result in appropriate error messages and that these don't pollute the log file or console. to setup for these tests -ensure there are a couple of shared projects in your workspace.</p> -<ul> -<li>Clear you log file before starting the tests and turn on the CVS quick diff provider. -<li>Perform an update, a synchronize, and open a file. The log should be empty and the operations should succeed. -<li>Disconnect from the network. -<li>Open a file. The CVS quick diff will fail and an error should be in the log. -<li>Synchronize all the shared projects. One error explaining the failures should be returned. -<li>Change the connection properties of one of the projects to point to an non-existing location. Then synchronize again, the error message should indicate that some succeeded and -others failed. But the user should no that the operation did complete and skipped the failed projects. -<li>Expand the invalid location in the CVS repositories view. An appropriate error should be shown. -</ul> - - -<a name="auth_problems00001.html"> -<h2>Authentication Problems</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 20:28:37 $</p> - -<p> - -Test the error reporting when authentication fails due to either, invalid username, password, hostname. This should be -tried with each CVS connection method: pserver, extssh, ext. - -</p> - - -<h1>Misc</h1> -<a name="00042.html"> -<h2>CVS Console</h2> -<p>Since: <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -There are a couple of preferences that controls the behavior and presentation of the console. These are: -<ul> -<li>font color: message color, error color, command line. Changing these should immediatly update the console view. -</ul> - - -<a name="encoding00001.html"> -<h2>Encoding Support</h2> -<p>Since: 3.0 M9<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -Answer comes here. - - -<a name="passwords00001.html"> -<h2>Password Management</h2> -<p>Since: 3.0 M9<br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<h3>Password Management</h3> - - -<a name="ext_connection_method00001.html"> -<h2>EXT</h2> -<p>Since: 2.0 <br> -Last Modified: $Date: 2004/06/01 15:23:56 $</p> - -<h3>Ext connection method</h3> - - -<h1>Validate Edit</h1> -<a name="validate_edit_editing_files00001.html"> -<h2>Editing Files</h2> -<p>Since: <br> -Last Modified: $Date: 2004/05/31 14:22:48 $</p> -<p> -These tests are to sanity check editors behavior relating to calling validateEdit. The tests will -try to cover all cases where files are changed by the validateEdit handler and changes are made -to the read-only bit. -</p><p> -These test cases outline the expected behavior of single file editors in terms -of calling validateEdit and handling of error conditions. All scenarios assume -that a repository provider is mapped to a project and has created a sandbox -with files that are marked read-only. -</p><p> -The -<a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.examples.filesystem/"> -org.eclipse.team.example.filesystem</a> plugin is a repository provider -that simulates a pessimistic workflow. You can use it to run these tests and validate (no pun intended) your validateEdit -editor support. To use the pessimistic provider, share a project with the repository provider called "File -System Pessimistic Example" and then you can add to control the files and -checkin/checkout will toggle the read-only bit and touch the file. You can -change the behavior of the validateEdit call via the pessimistic preference -page. For example, you can force the operation to fail and update contents of the file -when checked out. -</p> -<p> -These tests should be run against the following combinations of tools: -<ul> -<li>Different repository providers -<li>Single file editors (java, text) -<li>Multiple file editors (manifest editor, ...) -</il> -<!-- ------------------------------------------------------------------------------ --> -<h3>S1: Repository provider enabled and files are readable</h3> -<ol> -<li>Open a file that is not marked read-only in a project configured with a repository provider. -<li>Start editing the file, validate edit should not be called. -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S2: Validate edit called on first edit</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit returns OK, the users edit is accepted and shows up in the editor, and the file can be edited normally. -<li>The user saves the file, and then can continue editing without validateEdit being called. -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S2b: Validate edit cancelled</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit is cancelled, the users edit is not accepted and the file cannot be edited. -<li>The user should still be able to browse the contents of the file and trying to edit it again -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S2b: Validate edit fails with an error</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit is cancelled, the users edit is not accepted and the file cannot be edited. User should -be shown the error returned from the validateEdit provider. -<li>The user should still be able to browse the contents of the file and trying to edit it again -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S3: Validate edit called on subsequent edits if file changes state</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit returns OK, the user's edit is accepted and the file can be edited normally. -<li>The user saves the file, and then can continue editing without validateEdit being called. -<li>The user saves the file and then checks in the file while the editor is still open. -<li>After the checkin completes the user continues editing the file. -<li>Validate edit should be called again. -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S4: Validate edit not called after contents changed</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit returns OK, the user's edit is accepted and the file can be edited normally. -<li>The user saves the file, and then can continue editing without validateEdit being called. -<li>The user saves the file and keeps the editor opened. -<li>The user then un-checks out the file and new file contents are retreived from the server. -<li>The new file contents are loaded into the editor and validateEdit is not called. -<li> -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S5: Validate edit changes file contents editor not-dirty</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit returns OK and brings in new content from the server. -<li>The new content is loaded automatically because the editor isn't dirty yet. -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S6: Validate edit changes file contents editor dirty</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit returns OK and the file on disk doesn't change. -<li>The user continues editing the file and then checks it in. -<li>The editor remains open and dirty, the user continues editing. -<li>validateEdit is called because the file is now read-only and returns OK and brings in new content from the server. -<li>The editor detects the timestamp change and prompts about the conflict and provides -<a href="#reload_options">options</a> to the user. -<li>After the user selects his option and the user continues editing, the editor -will call validateEdit. -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S7: Read-only editors refreshing on checkout</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Checkout the file that brings in new content from the server. -<li>The editor should update with the new content from the server. -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S8: validate called on editor save</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit returns OK and the file on disk doesn't change. -<li>The editor remains open and dirty, the user continues editing. -<li>The user checks-n the file and then closes the editor. -<li>The user is prompted to save the file, then validate edit is called, and -the file is checked-out then saved. -</ol> -<!-- ------------------------------------------------------------------------------ --> -<h3>S9: validate called on editor save with new contents</h3> -<ol> -<li>Open a file that has been checked out as read-only from a repository provider. -<li>Start editing the file, validateEdit should be called. -<li>validateEdit returns OK and the file on disk doesn't change. -<li>The editor remains open and dirty, the user continues editing. -<li>The user checks-n the file and then closes the editor. -<li>The user is prompted to save the file, then validate edit is called, and -the file is checked-out then saved. -</ol> -</p> -<!-- -<hr> - -<a name="reload_options"><h3>Conflict Resolution Options for Editors</h3> -<pre> -Assumptions: - 1. Editors currently maintain a "dirty bit" indicating that the in-memory - buffer has been modified and not yet written to disk. Editors call - validateEdit() the if the file is read-only and the dirty bit is going - from the clean state to the dirty state. - 2. Editors can detect when the timestamp of the file has changed on disk - and prompt the user for the appropriate action. - -Suggestion: - Editors should maintain a separate bit, "must call validateEdit()". Any - modification of the buffer calls validateEdit() first if this bit is set. - It is initially set when the file is opened if the file is read-only. It - is cleared after a successful call to validateEdit(). It is set again - when the editor notices that a file has gone from read/write to read-only. - - If the "must call validateEdit()" bit ever goes from the cleared state to - the set state (except for when the file is initially opened), a later - successful call to validateEdit(), should should result in the following - actions: - - +-----------+------------------+----------------------------------------+ - | Dirty Bit | Timestamp Change | Editor Action | - | State | Detected | | - +-----------+------------------+----------------------------------------+ - | 0 | no | No action required | - +-----------+------------------+----------------------------------------+ - | 1 | no | No action required | - +-----------+------------------+----------------------------------------+ - | 0 | yes | Prompt user for reload/no-reload/merge | - +-----------+------------------+----------------------------------------+ - | 1 | yes | Prompt user for reload/no-reload/merge | - +-----------+------------------+----------------------------------------+ -</pre> ---> - -<a name="validate_edit_refactoring00001.html"> - - -Answer comes here. - - -</body></html> |