| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <html> |
| <head> |
| <title>eclipse 2.0 cvs plugin features</title> |
| |
| |
| |
| <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> |
| |
| |
| <meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type"> |
| |
| |
| <meta content="MSHTML 5.00.2614.3500" name="GENERATOR"> |
| </head> |
| <body> |
| <p>Back to <a href="../archivedReleases.php">Archived Releases</a></p> |
| <!-- Title --> |
| <table border="0" cellpadding="2" cellspacing="5" width="100%"> |
| <tbody> |
| <tr> |
| <td align="Left" width="54%"> |
| <p><font class="indextop">eclipse cvs features</font><br> |
| <font class="indexsub">overview of cvs 2.0 features </font></p> |
| </td> |
| <td width="46%"> </td> |
| </tr> |
| </tbody> |
| </table> |
| <!-- Introduction --> |
| <table border="0" cellpadding="2" cellspacing="5" width="100%"> |
| <tbody> |
| <tr> |
| <td align="Left" bgcolor="#0080c0" colspan="2" valign="Top"><b><font color="#ffffff" face="Arial,Helvetica"> |
| Eclipse Team Component</font></b></td> |
| </tr> |
| <tr> |
| <td><font face="arial,helvetica,geneva" size="-1"> |
| <p>Last Modified: May 14, 2002</p> |
| </font></td> |
| </tr> |
| </tbody> |
| </table> |
| <br> |
| <!-- Table of contents header --> |
| <table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%"> |
| <tbody> |
| <tr> |
| <td><font color="#000000" face="Arial,Helvetica" size="+1"><a name="toc"> |
| Table of contents: </a> |
| </font></td> |
| </tr> |
| </tbody> |
| </table> |
| <ul> |
| <!-- User questions subheader --><li><b>General Features</b> |
| <ol> |
| <li>Deleting folders and files</li> |
| <li>Renaming and moving folders and files</li> |
| </ol> |
| <!-- About Eclipse subheader --></li> |
| <li><b><a href="#sync"> Synchronize View :</a> |
| </b> |
| <ol> |
| <li><a href="#sync_1"> What is the sync view</a> |
| </li> |
| <li><a href="#sync_2"> Operations available in |
| the sync view</a> |
| </li> |
| <li><a href="#sync_3"> Resolving conflicts</a> |
| </li> |
| <li><a href="#sync_4"> CVS .# backup files </a> |
| </li> |
| <li><a href="#sync_5"> Saving files </a> |
| </li> |
| </ol> |
| <!-- User questions subheader --></li> |
| <li><b>Parallel development with branches</b> |
| <ol> |
| <li>Deciding to branch </li> |
| <li>Making a branch </li> |
| <li>Merging changes from one branch to another </li> |
| <li>Branches in the repository view </li> |
| <li>Further information on parallel development in CVS </li> |
| </ol> |
| <!-- About Eclipse Header --></li> |
| <li><b>Tags and versions</b> |
| <ol> |
| <li>Tags and project versions </li> |
| <li>How to tag </li> |
| <li>Moving tags </li> |
| <li>Tags in the repository view </li> |
| <li>Checking out from a version tag </li> |
| <li>Tagging files from the repositories view </li> |
| </ol> |
| <!-- About Eclipse Header --></li> |
| <li><b>Modules</b> |
| <ol> |
| <li>What are modules? </li> |
| <li>Modules in the repository view </li> |
| <li>Defining modules </li> |
| </ol> |
| <!-- About Eclipse Header --></li> |
| <li><b>Ignoring Resources</b> |
| <ol> |
| <li>Support for CVS ignore mechanisms</li> |
| <li>Derived resources in Eclipse </li> |
| <li>Eclipse global ignore mechanism </li> |
| </ol> |
| <!-- About Eclipse Header --></li> |
| <li><b>Comparing</b> |
| <ol> |
| <li>Comparing file revisions </li> |
| <li>Comparing folders and projects with a version or tag </li> |
| <li>Comparing with another branch </li> |
| <li>Comparing in the repository view </li> |
| </ol> |
| <!-- About Eclipse Header --></li> |
| <li><b>File types and keyword substitution</b> |
| <ol> |
| <li>Why does CVS care about file types? </li> |
| <li>Showing the file type </li> |
| <li>Defining file types </li> |
| <li>Keyword substitution </li> |
| <li>Integration with cvswrapper files </li> |
| </ol> |
| </li> |
| <!-- About Eclipse Header --><li><b>CVS Decorators</b> |
| <ol> |
| <li>What is a label decorator?</li> |
| <li>How does CVS decorate resources?</li> |
| </ol> |
| </li> |
| <!-- About Eclipse Header --><li><b>Connection Methods</b> |
| <ol> |
| <li>What is a connection method?</li> |
| <li>EXTSSH vs. EXT</li> |
| </ol> |
| </li> |
| </ul> |
| <!-- ---------------------- --><!-- General Features --><!-- ---------------------- --> |
| <table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%"> |
| <tbody> |
| <tr> |
| <td width="90%"><a name="general"><b><font color="#000000" size="+1"> |
| General Features: </font></b></a> |
| </td> |
| <td align="Right"><a href="http://www.eclipse.org/eclipse/faq/eclipse-faq.html#toc"><img align="Center" alt="Goto Top" border="0" height="16" src="up_nav.gif" width="16"> |
| top </a> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <!-- About Eclipse contents --> |
| <ol> |
| <li><b><a name="general_1">Deleting folders and files</a> |
| </b> |
| <p>If folders and/or files that are under CVS control are deleted, these |
| deletions are remember and will be communicated to the server on the next |
| commit (either using Team/Commit or a commit operation in the Synchronize |
| view).<br> |
| </p> |
| <hr size="1"></li> |
| <li><b><a name="general_2">Renaming and Moving folders and file</a> |
| </b> |
| <p>Renaming or moving a resource will be treated as a deletion at the |
| old location and a creation at the new location. The new resources will |
| not be place under CVS control until the user performs an Add to Version |
| Control (either from the Team menu or in the Synchronize view).</p> |
| </li> |
| </ol> |
| <!-- ---------------------- --><!-- Sync View --><!-- ---------------------- --> |
| <table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%"> |
| <tbody> |
| <tr> |
| <td width="90%"><a name="sync"><b><font color="#000000" size="+1"> |
| Synchronize View: </font></b></a> |
| </td> |
| <td align="Right"><a href="http://www.eclipse.org/eclipse/faq/eclipse-faq.html#toc"><img align="Center" alt="Goto Top" border="0" height="16" src="up_nav.gif" width="16"> |
| top </a> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <!-- About Eclipse contents --> |
| <ol> |
| <li><b><a name="sync_1">What is the sync view?</a> |
| </b> |
| <p>The synchronization view is an Eclipse way of synchronizing a local |
| workspace with an associated remote repository. For Eclipse CVS |
| users, you can use this view to add/commit/update/merge changes in day-to-day |
| development with your team. It provides an alternative to using CVS in |
| a command line centric manner.</p> |
| <p>By far, the sync view is one of the most powerful features of the Eclipse |
| CVS plugin.</p> |
| <hr size="1"></li> |
| <li><b><a name="sync_2">Operations available in the sync view</a> |
| </b> |
| <p>The table below shows all the possible synchronization states for resources |
| shown in the synchronization view and the CVS operations that can |
| be performed for each state. The operations marked with a * are considered |
| advanced operations and may only available from the context menu when |
| in the advanced mode (e.g. modes allow filtering the sync view to |
| show incoming, outgoing, or conflicting changes seperatly).</p> |
| <table height="124" border="1" width="99%"> |
| <tbody> |
| <tr> |
| <td width="27%"><b>Direction/Change Type</b></td> |
| <td width="25%"><b>Change</b></td> |
| <td width="25%"><b>Addition</b></td> |
| <td width="23%"><b>Deletion</b></td> |
| </tr> |
| <tr> |
| <td width="27%"><b>Incoming File or Folder</b></td> |
| <td width="25%" valign="Top"> |
| <p>1. <i>Update from Repository</i> (remote resource copied into |
| workspace)</p> |
| <p>2. <i>Override and Commit</i> (overrides the remote revision |
| with the revision in your workspace) *</p> |
| </td> |
| <td width="25%" valign="Top"> |
| <p>1. <i>Update from Repository</i> (remote resource copied |
| into workspace)</p> |
| <p>2. <i>Override and Commit</i> (deletes the remote resource) |
| *</p> |
| </td> |
| <td width="23%" valign="Top"> |
| <p>1. <i>Update from Repository</i> (deletes resources from |
| workspace)</p> |
| <p>2. <i>Override and Commit</i> (overrides the deletion and |
| commits the local resource to the repository) *</p> |
| </td> |
| </tr> |
| <tr> |
| <td valign="Middle"><b>Outgoing Unshared File or Folder Addition</b><br> |
| (An unshared resource is one that has not been added to CVS control)<br> |
| </td> |
| <td valign="Top">N/A<br> |
| </td> |
| <td valign="Top"> |
| <p>1. <i>Add to Version Control</i> (local resource added to version |
| control so it can be commited)</p> |
| <p>2. <i>Add to .cvsignore</i> (marks to resources as ignored. |
| The resources are removed from the sync view after being |
| ignored)</p> |
| 3. <i>Override and </i><i>Update</i> (local resources are deleted)*<br> |
| </td> |
| <td valign="Top">N/A<br> |
| </td> |
| </tr> |
| <tr> |
| <td width="27%"><b>Outgoing File or Folder<br> |
| </b>(An outgoing folder will never be a change)<br> |
| <br> |
| </td> |
| <td width="25%" valign="Top"> |
| <p>1. <i>Commit</i> (local resource commited to repository)</p> |
| <p>2. <i>Override and </i><i>Update</i> (remote resource copied |
| into workspace overriding local changes)*</p> |
| </td> |
| <td valign="Top" width="25%"> |
| <p>1. <i>Commit</i> (local resource commited to repository)</p> |
| <p>2. <i>Override and </i><i>Update</i> (local resources are deleted)*<br> |
| </p> |
| </td> |
| <td width="23%" valign="Top"> |
| <p>1. <i>Commit</i> (remote resource deleted from repository)</p> |
| <p>2. <i>Override and </i><i>Update</i> (remote resource copied |
| into workspace overriding the local deletion) *</p> |
| </td> |
| </tr> |
| <tr> |
| <td width="27%"> |
| <p><b>Conflicting File</b></p> |
| <p><b>a) auto-merge</b></p> |
| <p><b>b) manual-merge</b></p> |
| </td> |
| <td width="25%"> |
| <p>1a. <i>Override and </i><i>Update</i> (merges changes from |
| remote into local resource)</p> |
| <p>2a. <i>Override and Commit</i> (local resource copied to |
| repository overriding remote changes)</p> |
| <p>1b. <i>Override and </i><i>Update</i> (remote resource copied |
| into workspace overriding local changes)</p> |
| <p>2b. <i>Override and Commit</i> (same as 2a)</p> |
| </td> |
| <td width="25%">same as conflicting change</td> |
| <td width="23%">Resources are in sync, these aren't shown in the |
| sync view. </td> |
| </tr> |
| <tr> |
| <td valign="Middle"><b>Conflicting Folder</b><br> |
| </td> |
| <td valign="Top">A folder that is a conflicting change is an outgoing |
| folder deletion has children that are incoming or conflicting. The folder |
| state will be adjusting depending on the operations performed on the |
| children.<br> |
| </td> |
| <td valign="Top">A folder that is a conflicting addition indicates |
| that an unshared local folder already exists remotely. Operations performed |
| on the folder or any of its childen will adjust the local folder state |
| to match that of the remote.<br> |
| </td> |
| <td valign="Top">N/A<br> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <p>The sync view provides an easy way of performing tasks that are much |
| more difficult to accomplish by using the CVS command line |
| client. In addition, text files can be visually merged within |
| the sync view.</p> |
| <hr size="1"></li> |
| <li><b><a name="sync_3">Resolving conflicts</a> |
| </b> |
| <p>There are two categories of conflicting changes that will appear in |
| the sync view: </p> |
| <ul> |
| <li>text files that have non-conflicting line changes that can be merged |
| automatically using the update command or</li> |
| <br> |
| <li>text files that have conflicting line changes and binary or unknown |
| file types that must be merge manually</li> |
| </ul> |
| <br> |
| <p>For conflicting files that can be automatically merged, the Override |
| and Update operation in the sync view will ask to either perform |
| the merge or simply replace the local file with the remote |
| revision. For manual merge files the Override and Update operation |
| will replace the local file with the remote revision.<br> |
| <br> |
| If the file with the manual-merge is a text |
| file you can use the diff editors in the lower part of the |
| sync view to resolve the conflicting changes. You can either |
| use the Copy Right to Left buttons or simply copy and paste in |
| the editors to resolve the conflicts. Any changes must be saved (see |
| <a href="#sync_5"> Saving files</a> |
| below).</p> |
| <hr size="1"></li> |
| <li><b><a name="sync_4">CVS .# backup files</a> |
| </b> |
| <p>When CVS performs merges with the update command it saves .# backup |
| files of the working copy of a files before the merge. The update |
| command from the sync view will not create these files, instead use |
| local history to retrieve a copy of the file before the merge.</p> |
| <hr size="1"></li> |
| <li><b><a name="sync_5">Saving files</a> |
| </b> |
| <p>When you select a file in the sync view's top pane the local, remote, |
| and if applicable, the ancestor file contents are shown |
| in the bottom half of the view. You can edit the local file |
| at anytime (either directly or using the sync view copy actions) and when |
| the save action (context menu or if prompted to save) is performed |
| the file will be saved to disk at that moment. They aren't buffered |
| and saved at a later time. <br> |
| <br> |
| Files that have been edited and save in the sync view will remain |
| in the view until the user performs a Confirm Merge operation on the |
| file which indicates that the conflict has been resolved.<br> |
| </p> |
| </li> |
| </ol> |
| <!-- ---------------------- --><!-- Parallel Development --><!-- ---------------------- --> |
| <table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%"> |
| <tbody> |
| <tr> |
| <td width="90%"><b><font color="#000000" size="+1">Parallel Development |
| with branches:</font></b></td> |
| <td align="Right"><a href="http://www.eclipse.org/eclipse/faq/eclipse-faq.html#toc"><img align="Center" alt="Goto Top" border="0" height="16" src="up_nav.gif" width="16"> |
| top </a> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <ol> |
| <li><b><a name="branch_1">Deciding to branch</a> |
| </b> |
| <p>The desire to create a branch can be the result of several scenarios. |
| In one common secenario, a designer may decide to create a branch |
| after making modifications to one or more projects shared with HEAD. |
| They would like to store the modifications in the repository but doing |
| so may leave the project(s) in an unstable or otherwise undesirable |
| state. By creating a branch, the designer can store the modifications |
| in the repository without affecting the state of the project(s) in HEAD. |
| At a later time, when modifications on the branch have reached a stable |
| state, the designer can merge the modifications into HEAD. </p> |
| <p>Another common scenario involves adding critical bug fixes to a version |
| of a project that is included in an official release of a product. |
| All important versions of a project stored in CVS should be tagged |
| so that product releases based on the project versions can be recreated |
| easily. Assuming that version tagging was performed, a designer can load |
| the code base of a released product by loading the corresponding versions |
| of the projects that constitute the product release. Patches can then be |
| created to fix any critical bugs in the product release. Once created, these |
| modifications need to be stored in the repository so future critical |
| bug fixes to the product release will be made on top of the actual code |
| in the product release. However, CVS does not allow modifications made |
| to loaded versions to be committed back into the repository. Also, it |
| would be inappropriate to store these changes in HEAD as the development |
| in HEAD may be months ahead of the version in the product release (although |
| the bug fixes should be made in HEAD as well, if appropriate). In this situation, |
| the designer can create a banch off the project version and commit the modifications |
| to the branch. The project branch should still be versioned for every official |
| patch release so that the designer can keep track of what code is in each |
| release.</p> |
| <p>More information on banching can be found in Open Source Development |
| with CVS, 2nd Edition.<br> |
| </p> |
| <hr size="1"></li> |
| <li><b><a name="branch_2">Making a branch</a> |
| </b> |
| <p>Both of the scenarios described above begin with a local working copy |
| of a project shared with a CVS repository. Creating a branch on a |
| local working copy typically consists of three operations:</p> |
| <ol> |
| <li>Tag the local working copy with the branch tag</li> |
| <li>Tag the local working copy with a version tag (to be used when |
| merging)</li> |
| <li>Start working in the branch.<br> |
| </li> |
| </ol> |
| <p>In Eclipse, the CVS branch action (available in the Team context menu |
| of resources in the navigator) presents a wizard that can perform |
| all three of these operations. It requires the specification of a |
| branch tag and optionally allows the specification of a version tag |
| that acts as the starting point when merging the branch back to HEAD |
| (the user will be required to provide a version tag unless they already |
| have a version loaded). Also, it provides the option of starting to |
| work in the branch. Enabling this option will update the local |
| working copy to be shared with the branch. Subsequent synchronization |
| operations will be performed against the branch. Resources subsequently |
| commited will not effect other developers working in HEAD until the |
| branch is merged with HEAD.</p> |
| <hr size="1"></li> |
| <li><b><a name="branch_3">Merging changes from one branch to another</a> |
| </b> |
| <p>At some point, a designer will wish to merge the modifications they |
| have made in a branch back into HEAD (or another branch depending |
| on how a development group has decided to share work). This merge |
| is complicated by the fact that other developers may have made modifications |
| in the target branch (usually HEAD) that overlap with the modifications |
| made in the source branch. Merging is perfomed by loading the target |
| branch into the local workspace and then merging the source branch |
| into the target. Therefore, merging one branch with another involves |
| similar resource states as described in the section on synchronization |
| except that the states are resticted to those involving incoming and |
| conflicting resource modifications.</p> |
| <p>Merging is performed using the merge wizard. To perform a merge:</p> |
| <ol> |
| <li>load the target brach into the workspace</li> |
| <li>select Merge from the Team menu of a projects context menu</li> |
| <li>select starting point (version defined when creating the branch)</li> |
| <li>select end point (usually the branch itself)<br> |
| </li> |
| </ol> |
| <p>Upon finish, the designer is presented with a merge editor that behaves |
| similarily to the synchronize view with the exception that ony incoming |
| changes and conflicts are considered. Once the merge in complete, |
| the designer should then perform any tests to ensure that the code |
| still works before synchronizing and committing the modifications to |
| the target branch.</p> |
| <hr size="1"></li> |
| <li><b><a name="branch_4">Branches in the repositories view</a> |
| </b> |
| <p>In the repositories view, the contents of HEAD or another branch can |
| be viewed. When a repository entry is expanded, several categories |
| are shown including HEAD and Branches. Expanding HEAD shows the root |
| level folders of the repository. Further expanding a particular project |
| will show the resource revisions that are associated with the project |
| in HEAD. Expanding the Branches category shows a list of all known branches. |
| Like expanding HEAD, expanding one of these branches shows the root level |
| folders of the repository and further expansion will lead to the revisions |
| contained in that branch. It should be noted that folders are considered |
| to be in HEAD and all branches. For this reason, a folder may appear empty |
| in the repositories view. This could be an empty folder or a folder that |
| contains resources in another branch (or version). Projects can be checked |
| out from a branch just as they can be checked out from HEAD.</p> |
| <p>Initially, Eclipse may not know about branches that are define for |
| a repository or project. A designer can define branches manually from |
| the context menu of the Branches category entry using the Define Branch |
| operation or can auto-discover branch and version tags using the Configure |
| Branches and Versions operation available from the context menu of any |
| foldr in the Repositories view. </p> |
| <p>The Repository View can also be used to move branch tags to a different |
| base version of a project in the same way a version tag can be moved |
| (see <a href="#tag_3">Moving Tags</a> |
| ).<br> |
| </p> |
| <hr size="1"></li> |
| <li><b><a name="branch_5">Further information on parallel development in |
| CVS</a> |
| </b> |
| <p><b> Websites</b><br> |
| </p> |
| <p><a href="http://www.cvshome.org/">CVS Home Page</a> |
| </p> |
| <p><b>Books</b></p> |
| <p>Open Source Development with CVS, 2nd Edition, by Karl Fogel and Moshe |
| Bar, Coriolis Technology Press, 2001<br> |
| (portions available <a href="http://cvsbook.red-bean.com/"> |
| on-line</a> |
| )</p> |
| </li> |
| </ol> |
| <!-- ---------------------- --><!-- Tags and Project Versions --><!-- ---------------------- --> |
| <table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%"> |
| <tbody> |
| <tr> |
| <td width="90%"><b><font color="#000000" size="+1">Tags and Project |
| Versions</font></b></td> |
| <td align="Right"><a href="http://www.eclipse.org/eclipse/faq/eclipse-faq.html#toc"><img align="Center" alt="Goto Top" border="0" height="16" src="up_nav.gif" width="16"> |
| top </a> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <ol> |
| <li><b><a name="tag_1">Tags and project versions</a> |
| </b> |
| <p>Tags are used in CVS to group a set of resource revisions for later |
| retrieval. Hence, tags are often used to identify the versions of |
| a particular project or set of projects. In Eclipse, tagging can be |
| performed on projects, folders or files. However, the repositories |
| view only shows tags at the project level (and refers to them as versions).</p> |
| <p>Tags are also used in CVS to identify branches, as described in the |
| previous section.</p> |
| </li> |
| <li><b><a name="tag_2">How to tag</a> |
| </b> |
| <p>Tagging is performed by selecting the Team/Tag item from a resource's |
| context menu. The tag is then applied to the remote resource revisions |
| corresponding to the resources that exist in the local workspace. The |
| user should commit any local changes if they desire those changes to |
| be included in the tagged set of resources. </p> |
| </li> |
| <li><b><a name="tag_3">Moving Tags</a> |
| </b> |
| <p>By default, a tag can only be applied to a set of resources if the |
| tag hasn't been previously applied to any of the resources being tagged. |
| However, the user may choose to force the tag to be moved to the resource |
| revisions in the current line up. The ability to move tags is available |
| in the Repositories view using the Tag with Existing operation. </p> |
| </li> |
| <li><b><a name="tag_4">Tags in the repositories view</a> |
| </b> |
| <p>Tags are shown in the repositories view on a per project basis. Expanding |
| the Versions category shows the list of projects and expanding a project |
| shows the list of versions defined for that project. Version names |
| can be manually added for a project or can be auto-discovered by performing |
| an Configure Branches and Versions operation on a file in the project |
| (in HEAD). Expanding a version will show the folders and resource revisions |
| for the resources in the version. As mentioned previously, folders are |
| considered to be in all branches and versions even if they are empty. |
| </p> |
| </li> |
| <li><b><a name="tag_5">Checking out from a version tag</a> |
| </b> |
| <p>The repository view allows a version of a project to be checked out |
| in the same mannor as projects can be checked out from branches. However, |
| changes made to a version cannot be committed back to the repository. |
| To commit changes to a version, the user must create a branch off the |
| version (as described in the previous section).</p> |
| </li> |
| <li><b><a name="tag_6">Reverting to a version</a> |
| </b> |
| <p>It is possible to revert the resources in HEAD or a branch to the |
| contents of resource revisions from a particular version. This is done using |
| the Compare editors. First, load a project, folder or file from HEAD or the |
| branch to be reverted. Then perform a Compare With/Branch or Version on the |
| resource(s) to be reverted. The Compare editor can then be used to copy remote |
| contents into the local resources and to save these changes. </p> |
| </li> |
| <li><b><a name="tag_7">Tagging from the repositories view</a> |
| </b> |
| <p>Tagging can be performed from the repositories view by selecting a |
| remote resource(s) and performing a Tag as Version operation. </p> |
| </li> |
| </ol> |
| <!-- ---------------------- --><!-- Modules --><!-- ---------------------- --> |
| <table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%"> |
| <tbody> |
| <tr> |
| <td width="90%"><b><font color="#000000" size="+1">Modules</font></b></td> |
| <td align="Right"><a href="http://www.eclipse.org/eclipse/faq/eclipse-faq.html#toc"><img align="Center" alt="Goto Top" border="0" height="16" src="up_nav.gif" width="16"> |
| top </a> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <ol> |
| <li><b><a name="tag_1">What is a module</a> |
| </b> |
| <p>CVS sometimes referes to all remote folders as modules. However, CVS |
| also supports the definition of modules which do not necessarily correspond |
| directly to a remote folder. This section describebs these modules.</p> |
| </li> |
| <li><b><a name="tag_2">Modules in the repositories view</a> |
| </b> |
| <p>By default, the Repositories view lists the folders that exist in |
| a repository. The view can be toggled to show the modules that are defined |
| in the CVSROOT/modules file by using the drop down menu in the title bar |
| of the view. In Show Modules mode, only module definitions are shown and |
| can be checked out. Once a module is checked out, the local copy of a module |
| is treated no differently than other CVS projects. </p> |
| </li> |
| <li><b><a name="tag_3">Defining modules</a> |
| </b> |
| <p>Modules are defined in the CVSROOT/modules file. See the CVS documentation |
| for more information about defining modules.</p> |
| </li> |
| </ol> |
| <!-- ---------------------- --><!-- Modules --><!-- ---------------------- --> |
| <table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%"> |
| <tbody> |
| <tr> |
| <td width="90%"><b><font color="#000000" size="+1">Ignoring Resources</font></b></td> |
| <td align="Right"><a href="http://www.eclipse.org/eclipse/faq/eclipse-faq.html#toc"><img align="Center" alt="Goto Top" border="0" height="16" src="up_nav.gif" width="16"> |
| top </a> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| <ol> |
| <li><b><a name="tag_1">Support for CVS ignore mechanisms</a> |
| </b> |
| <p>In most cases, newly created resources that are children of a folder |
| that is under CVS control are eventually placed under CVS control and committed |
| to the repository. However, in some cases, it may be the user's desire to |
| exclude certain files from CVS control. For example, files and folders that |
| are the output of a build process are often not stored in the repository |
| since they can be derived from the files that are in the repository. For this |
| reason, CVS requires new resources to be explicitly added to CVS control before |
| they can be committed. Although CVS will not commit a resource until it has |
| been added to CVS control, CVS will still consider the file during some operations. |
| For instance, these resources will appear in the Synchronize view as outgoing |
| additions. </p> |
| <p>Excluding a resource entirely from CVS operations is referred to as |
| ignoring that resource. Ignoring a resource prevents the resource from appearing |
| in the Synchronize view or from being added when an ancestor is added. The |
| Team/Add to Version Control opetion can be performed on a new folder and this |
| will add all non-ignored children to CVS control. Also, ignored resources |
| are not decorated by the CVS decorators.</p> |
| <p>One of the mechanisms that CVS provides for ignoring resources is |
| the .cvsignore file. When a .cvsignore file exists in a folder that is under |
| CVS control, CVS will ignore all resources which reside in that folder whose |
| names match one of the patterns in the .cvsignore file. The Add to .cvsignore |
| operation is available from the Team menu and in the Synchronize view and |
| can be performed on newly created resources that are not under CVS control. |
| This operation presents the user with a dialog that will aid them in adding |
| the desired pattern to the proper .cvsignore file. The user can choose to |
| add the file name as is, add the *.ext pattern (where ext is the extension |
| of the selected file or files) or specify their own pattern. Patterns consist |
| of valid file/folder name characters as well as the wildcards "*" (which |
| matches any string of one or more characters) and "?" (which matches any single |
| character).</p> |
| <p>An ignored resource can still be explicitly added to CVS control using |
| the Add to Version Control operation. This is supported because there are |
| several global mechanisms for ignoring resources. For one, CVS has a set of |
| standard file name patterns that are ignored (see the CVS documentation for |
| a complete list). There is also a CVSROOT/cvsignores file that defines global |
| ignores for a repository (Eclipse currently does not honor these ignores). |
| There are also Eclipse derived resources and an Eclipse ignore facility, described |
| in the sections that follow.<br> |
| </p> |
| </li> |
| <li><b><a name="tag_2"></a> |
| Derived resources in eclipse</b></li> |
| <p>Tools in Eclipse that generate derived resources will mark the resources |
| as derived. The Eclipse CVS client will automatically ignore any resource |
| that has been marked as derived. For example, using the JDT to compile java |
| code will result in th creation of *.class files. These files are marked |
| as derived by JDT and are therefore ignored by CVS. </p> |
| <li><b><a name="tag_2">Eclipse global ignore mechanism</a> |
| </b> |
| <p>Eclipse also provides a mechanism for specifying a set of file patterns |
| that will be automaticaly ignored. This is useful if a user is using an external |
| tool which generates derived resources which do not get marked internall as |
| derived by Eclipse. The ignored file patterns can be specified on the Team/Ignored |
| Resources preference page. Patterns follow the usual format, consisting of |
| valid file name characters and the wildcards * and ?. An entered pattern |
| can be enabled or disabled on the preferecne page as well.<br> |
| </p> |
| </li> |
| </ol> |
| <table bgcolor="#cccccc" border="0" cellpadding="2" cellspacing="0" width="100%"> |
| <tbody> |
| <tr> |
| <td align="Right"><a href="http://www.eclipse.org/eclipse/faq/eclipse-faq.html#toc"> |
| top </a> |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| </body> |
| </html> |
