Skip to main content
aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat (limited to 'tests/org.eclipse.team.tests.cvs.core/toc.html')
-rw-r--r--tests/org.eclipse.team.tests.cvs.core/toc.html1955
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-&gt;Branch, Replace With-&gt;Branch or Version, and Team-&gt;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>

Back to the top