| <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.1 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.20</span><br> |
| Latest Development: <span style="font-weight: bold;">1.12.12</span><br> |
| CVS NT: <strong>2.5.01.1927</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">Michael Valenta<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="#commit00001.html">Commit</a> |
| <ul> |
| <li><a href="#commit00002.html">Committing Changes</a> |
| <ul> |
| </ul> |
| </ul> |
| <li><a href="#tags00001.html">Tags</a> |
| <ul> |
| <li><a href="#tags00002.html">Tag Selection in Dialogs</a> |
| <ul> |
| </ul> |
| <li><a href="#tags00003.html">Tag Caching</a> |
| <ul> |
| </ul> |
| </ul> |
| <li><a href="#00012.html">Branch/Merge</a> |
| <ul> |
| <li><a href="#00022.html">Performing a Merge</a> |
| <ul> |
| </ul> |
| <li><a href="#00013.html">Synchronize View</a> |
| <ul> |
| </ul> |
| <li><a href="#branch00001.html">Branching</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> |
| <li><a href="#keys00001.html">Key Bindings</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> |
| <li><a href="#logical00001.html">Logical Resource Support</a> |
| <ul> |
| <li><a href="#logical00002.html">Java Packages</a> |
| <ul> |
| </ul> |
| <li><a href="#logical00003.html">Working Sets</a> |
| <ul> |
| </ul> |
| </ul> |
| </ul> |
| <h1>Repositories View</h1> |
| <a name="repoview_basics00001.html"> |
| <h2>Basics</h2> |
| <p>Since: <br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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> |
| |
| <p> |
| Also ensure that the tag filtering in the dialog works properly. |
| |
| |
| <a name="00047.html"> |
| <h2>With file revision</h2> |
| <p>Since: <br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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>Change Sets Layout</h2> |
| <p>Since: 3.1 M2<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <h3>Change Sets for incoming changes</h3> |
| |
| To perform these scenarios you will need to get one or more projects |
| in your workspace that have many incoming changes. Perferably |
| all the changes will have commit comments and some files will share |
| a comment. Once you have this setup, you can perform the following sub-scenarios. |
| |
| <h4>Enabling/disabling Change Sets</h4> |
| <ol> |
| <li>Synchronize the projects with HEAD, enable change set mode and |
| ensure that the files appear in the proper change sets. Also ensure that |
| the proper sub-layout is used by expanding some of the nodes in the tree. |
| <p> |
| <li>With some nodes expanded and additionally one or more selected, |
| disable Change Sets. The same nodes should remain expanded and selected. |
| <p> |
| <li>With the same nodes selected and expanded, re-enable change sets. |
| The expansion should remain. There may be more expanded if the same |
| expanded project or folder appears in multiple change sets. The selection |
| will remain unless there are two entries for the same resource (i.e. if a project |
| was selected and it apears in multiple sets, it will no longer be expanded). |
| </ol> |
| You should also confirm that markers and conflicts are properly propogated to |
| parent nodes. |
| <h4>Change Set Layouts</h4> |
| Now try the various sub-layouts (Flat, Tree and Compressed) and ensure that switching |
| is performant and that the resulting tree nodes are correct. |
| |
| <h4>Change Set Modes</h4> |
| <ol> |
| <li>Switch between the various modes and ensure that the displayed nodes are correct. |
| Also ensure that expansion and seleciton is maintained. |
| <li>Only Incomign and Outgoing mode shw change sets. |
| </ol> |
| |
| <h4>Updating</h4> |
| With several nodes expanded, perform an update on one or more files |
| that are incoming changes. |
| Ensure that the updated files are removed from the view and that |
| other expanded nodes remain expanded. |
| |
| <h3>Outgoing Sets</h3> |
| |
| The following aspects of outgoing change sets should be tested. |
| <ol> |
| <li>Modified files can be added to a new or existing change set. Ensure that |
| when they are added, he file remains visible in the Sync view. |
| <li>Files in a change set can be transfered to another change set |
| <li>If there is a default change set, any modified file that is not already |
| part of a change set is placed in the default set. Files that are already |
| in a set should stay in that set if more changes are made to the files. |
| <li>The title and comment of a change set can be changed. |
| <li>Layout and modes changes work properly for outgoing change sets in the |
| Synchronize view. |
| <li>ing one or more files in a change set will result in a commit |
| dialog that is primed with the comment from the set. |
| <li>change sets (including which is the default), are preserved accross restarts. |
| </ol> |
| |
| |
| <a name="sync00001.html"> |
| <h2>Scenarios</h2> |
| <p>Since: <br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</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>Commit</h1> |
| <a name="commit00002.html"> |
| <h2>Committing Changes</h2> |
| <p>Since: 3.1 M4<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <h3>Commiting changes to existing files</h3> |
| <ol> |
| <li>Edit some existing files in a CVS project |
| <li>Choose Team>Commit on the project from the Navigator |
| <li>The commit dialog should show a preview of the files that are to be committed and allow a commit comment to be entered. |
| </ol> |
| <p> |
| Some things to try: |
| <ul> |
| <li>Committing a project (or selected resources) that contain no changes will prompt to indicate this. |
| <li>Files can be removed from the preview area and these will be excluded from the commit. |
| <li>Clicking OK without entering a comment should prompt. |
| <li>Emptying the preview area will disable the Finish and show a "no changes" message. |
| <li>Try different page layouts (compressed, tree and flat) |
| </ul> |
| |
| <h3>Commiting new files</h3> |
| <ol> |
| <li>Add a few new files to a project including some with unknown extensions and some with no extensions. |
| <li>Choose Team>Commit on the project from the Navigator |
| <li>The first page of the commit wizard will allow you to configure the file types for any new files whose content type |
| cannot be determined. |
| <ul> |
| <li>Configure some to be remembered and others to be only applied to this commit (verify after that this was done properly) |
| </ul> |
| <li>Click Next and verify that the content type was determined properly. |
| <li>Choose to ignore one of the files and verify that the file is removed and the .cvsignore appears. |
| </ol> |
| |
| <h3>Commiting files contained in a Change Set</h3> |
| <ol> |
| <li>From the Synchronize view, select all the changes from the same Change Set. |
| <li>Choose Commit and verify that the comment in the commit dialog is the one from the change Set. |
| </ol> |
| |
| |
| <h1>Tags</h1> |
| <a name="tags00002.html"> |
| <h2>Tag Selection in Dialogs</h2> |
| <p>Since: 3.1 M4<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| Tag lists appear in many dialogs: |
| <ul> |
| <li>Replace with Branch or Version |
| <li>Compare with Branch or Version |
| <li>Share of existing project |
| <li>Switch to Another Branch or Versions |
| <li>Tag with Existing |
| <li>Tag as Version |
| </ul> |
| |
| <p> |
| In each of these places, typing in the tag text field will filter the list of shown tags. |
| The option to Refresh and Configure tags should also be present. Refreshing behavior should be as follows: |
| |
| <ol> |
| <li>If an auto-refresh file (.project by default) exists and has tags, the tags are obtained from the file. |
| <li>If there is no auto-refresh file, the log command is used to determine if there are any tags in the files |
| that are direct children of the remote folder. |
| <li>If no tags are found, the user is prompted to either perform a deep log to find any tags or configure the |
| tags manually. |
| </ol> |
| |
| |
| <a name="tags00003.html"> |
| <h2>Tag Caching</h2> |
| <p>Since: 3.1 M4<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| Discovered tags are cached locally to improve performance. Caching is done in the following ways: |
| |
| <ol> |
| <li>Tags discovered for local resources are cached with the rmeote folder that the resource's project is mapped to. |
| <li>Tags discovered for remote resources are cached with the resource if it is a folder or the resource's parent if it is a file. |
| </ol> |
| |
| To test this, you can try one or more of the following: |
| <ol> |
| <li>Perform Compare With on folders and subfolders in the repositories view. The first time, you will need to perform a Refresh \ |
| but subsequent times, the tags should be cached. |
| <li>Load non-root folders as projects and ensure tags are cached and obtained properly. |
| <li>Perform Tag with Existing in the History view and ensure that tags are obtained from the file |
| </ol> |
| |
| |
| <h1>Branch/Merge</h1> |
| <a name="00022.html"> |
| <h2>Performing a Merge</h2> |
| <p>Since: 3.1<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</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. |
| |
| <p> |
| Things to try: |
| <ul> |
| <li>Use content assist to select an existing branch for the end tag. A root versions should ne automatically found if it exists. |
| <li>Choose to perform the merge into the local workspace. Ensure it works with and without a start tag. |
| </ul> |
| |
| <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>Scenario 3: Direct Merge</h3> |
| |
| Perform a Team>Merge and choose to merge directly intro the workspace. Try both the |
| case with a base tag and without it. |
| |
| <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: 2006/06/13 20:12:27 $</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> |
| |
| <a name="branch00001.html"> |
| <h2>Branching</h2> |
| <p>Since: 3.1 M4<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <ol> |
| <li>Choose Team>Branch from the context menu of the Navigator. |
| <li>Enter a branch tag. |
| <li>Verify that a version tag is proposed for the branch |
| <li>Click OK and verify that the tags are applied and the local project is mapped to the branch |
| </ol> |
| <p> |
| Some things to try: |
| <ul> |
| <li>Uncheck the "start working on branch" option and verify that the local project is not moved to the branch. |
| <li>Branch a loaded version and verify that the tag from the project is used as the root. |
| <li>Ensure that the content assist on the branch text widget shows branches from other projects in the workspace |
| that do not exist on the project being branched. |
| <li>Branch with local changes and ensurethat they remain and can be committed to the branch |
| </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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</p> |
| |
| Using HTTP and SOCKS5 proxies. |
| |
| |
| <a name="00031.html"> |
| <h2>Key Generation</h2> |
| <p>Since: <br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 3.1 <br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <p>You can customize the label decorations via the preference page. |
| The customizations will |
| take effect when apply is pressed. Resetting the defaults should work. |
| </p> |
| <p> |
| You can also configure the font and color used for various resources states. |
| There should be a link from the CVs label decorations preference page to the |
| general colors and fonts preference page. |
| |
| |
| <a name="00038.html"> |
| <h2>Decorations in the Synchronize pages</h2> |
| <p>Since: 3.0 M8<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</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: 2006/06/13 20:12:27 $</p> |
| |
| Answer comes here. |
| |
| |
| <a name="passwords00001.html"> |
| <h2>Password Management</h2> |
| <p>Since: 3.0 M9<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <h3>Password Management</h3> |
| |
| |
| <a name="ext_connection_method00001.html"> |
| <h2>EXT</h2> |
| <p>Since: 2.0 <br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <h3>Ext connection method</h3> |
| |
| |
| <a name="keys00001.html"> |
| <h2>Key Bindings</h2> |
| <p>Since: 3.1<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <p>Activate the CVS menu and assign keybindings to the various CVS commands. |
| Ensure that they work as expected. |
| |
| |
| <h1>Validate Edit</h1> |
| <a name="validate_edit_editing_files00001.html"> |
| <h2>Editing Files</h2> |
| <p>Since: <br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</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, ...) |
| </ul> |
| <!-- ------------------------------------------------------------------------------ --> |
| <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"> |
| |
| |
| These tests are a sanity check that workbench, JDT and other tools refactorings behave |
| properly with respect to validate Edit. For a repository providers that supports |
| a pessimistic workflow, the following scenarios should result in the invocation |
| of the validate edit callback and should include a UI context which allows prompting. |
| <p> |
| The following scenarios are stated in terms of the Navigator view and JDT. Other tools |
| should translate them to a set of scenarios that make sense for the tool. |
| |
| <!-- ------------------------------------------------------------------------------ --> |
| <h3>S1: Search and Replace</h3> |
| <ol> |
| <li>Select one or more projects or folders and choose Search/File. |
| <li>Enter a string known to exist in multiple files and click Replace |
| <li>Enter a new string that differs from the one searched for. |
| </ol> |
| <!-- ------------------------------------------------------------------------------ --> |
| <h3>S2: Single file content modification</h3> |
| <ol> |
| <li>Open a Java file that is read-only |
| <li>Perform any of the Java Source operations (e.g. toggle comment) |
| <li>Ensure that validate edit is invoked |
| </ol> |
| <!-- ------------------------------------------------------------------------------ --> |
| <h3>S3: Multiple file content modification</h3> |
| <ol> |
| <li>Ensure all files in your workspace are read-only |
| <li>Perform a Java/Refactoring such as a method or class rename. |
| <li>Ensure that validate edit is invoked at most once per project involved. |
| </ol> |
| |
| |
| <h1>Logical Resource Support</h1> |
| <a name="logical00002.html"> |
| <h2>Java Packages</h2> |
| <p>Since: 3.1<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <p>Ensure that CVS operations such as Update and Commit are performed only |
| on the files in a Java package and not on the subpackages when the operations |
| are launched from the Java Packages Explorer. |
| |
| |
| <a name="logical00003.html"> |
| <h2>Working Sets</h2> |
| <p>Since: 3.1<br> |
| Last Modified: $Date: 2006/06/13 20:12:27 $</p> |
| |
| <p> |
| Configure the Java Packages Explorer to show Working Sets. Populate the |
| working sets with various combinations of shared and unshared projects and |
| ensure that CVS operations can be performed directly on the working sets if they |
| contain at least one shared project. |
| |
| |
| </body></html> |