| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <html lang="en"> |
| <head> |
| |
| <meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2015. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > |
| |
| |
| <meta http-equiv="Content-Type" |
| content="text/html; charset=ISO-8859-1"> |
| |
| <meta http-equiv="Content-Style-Type" content="text/css"> |
| |
| <link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1" |
| type="text/css"> |
| <title>Team support with CVS</title> |
| |
| <meta name="keyword" content="team"> |
| </head> |
| <body style="background-color: rgb(255,255,255);"> |
| |
| <h1 class="Head">Team support with CVS</h1> |
| |
| <p class="Para">In the Concurrent Versions System (CVS) team programming environment, |
| team members do all of their work in their own Workbenches, isolated from |
| others. Eventually they will want to share their work. They do this via |
| a CVS Repository.</p> |
| |
| <h2 class="Para">Branches</h2> |
| |
| <p class="Para">CVS uses a branch model to support multiple courses of work |
| that are somewhat isolated from each other but still highly interdependent. |
| Branches are where a development team shares and integrates ongoing work. |
| A branch can be thought of as a shared workspace that is updated by team |
| members as they make changes to the project. This model allows individuals |
| to work on a CVS team project, share their work with others as changes |
| are made, and access the work of others as the project evolves. A special |
| branch, referred to as HEAD, represents the main course of work in the |
| repository (HEAD is often referred to as the trunk).</p> |
| |
| <h2 class="Para">Sharing work</h2> |
| |
| <div class="Topic"> |
| <p class="Para">As team members produce new work, they share this work by |
| <i>committing</i> those changes to the branch. Similarly, when they |
| wish to get the latest available work, they <i>update</i> their local |
| workspaces to the changes on the branch. Thus the branch is constantly |
| changing, moving forward as team members submit new work.</p> |
| |
| <p class="Para">The branch effectively represents the current state of the |
| project. At any point a team member can update their workspaces from the branch and know |
| they are up to date.</p> |
| |
| <div class="Figure"> |
| <div> <img src="../images/ref-9.png" |
| alt="Interaction with Branches and Workbenches" > |
| </div> |
| </div> |
| |
| <div class="XRefList"> </div> |
| </div> |
| |
| <div class="Topic"> |
| <h2>Optimistic team model</h2> |
| |
| <p class="Para">CVS provides two important features required for working in |
| a team:</p> |
| |
| <ul> |
| <li> |
| <p class="Para">A history of the work submitted by the team </p> |
| </li> |
| <li> |
| <p class="Para">A way to coordinate and integrate this work </p> |
| </li> |
| |
| </ul> |
| |
| <p class="Para">Maintaining history is important so that one can compare the |
| current work against previous drafts, revert to older work that is better, and |
| so on. Coordinating the work is critical so that there exists one definition |
| of the current project state, containing the integrated work of the |
| team. This coordination is provided via the branch model.</p> |
| |
| <p class="Para">An optimistic model is one where any member of the team can |
| make changes to any resource he or she has access to. Because |
| two team members can commit to the branch changes to the same resource, |
| conflicts can occur and must be dealt with. This model is termed <i> |
| optimistic</i> because it is assumed that conflicts are rare.</p> |
| |
| <h2>Recommended work flow</h2> |
| |
| <p class="Para">Usually resources do not exist in isolation, they typically |
| contain implicit or explicit dependencies on other resources. For |
| example, Web pages have links to other Web pages, and source code has |
| references to artifacts described in other source code resources. |
| No resource is an island.</p> |
| |
| <p class="Para">As resources are committed to the branch, these dependencies |
| can be affected. Ensuring the integrity of the dependencies is important |
| because the branch represents the current project state: at any point |
| a team member could take the branch contents as a basis for new work.</p> |
| |
| <p class="Para">The ideal work flow therefore is one in which the branch integrity |
| is preserved. </p> |
| |
| <h3 class="Para"><a name="IdealWorkFlow">Ideal flow enumerated</a></h3> |
| |
| <p class="Para">The ideal work flow proceeds as follows:</p> |
| |
| <ol> |
| <li> |
| <p class="Para">Start fresh. Before starting work, update the resources |
| in the workspace with |
| the current branch state. If you are sure that you have no local |
| work that you care about, the fastest way to get caught up is to |
| select the projects you are interested in from the branch (or HEAD) |
| and select <b>Checkout</b> (or <b>Replace with > Latest from Repository</b> |
| if the projects already exist locally). This will overwrite your |
| local resources with those from the branch. </p> |
| </li> |
| <li> |
| <p class="Para">Make changes. Work locally in your Workbench, creating |
| new resources, modifying existing ones, saving locally as you go. |
| </p> |
| </li> |
| <li> |
| <p class="Para">Synchronize. When you are ready to commit your work, synchronize |
| with the repository.</p> |
| |
| <ol type="a"> |
| <li> |
| <p class="Para">Update. Examine incoming changes and add them to your |
| local Workbench. This allows you to determine if there are changes |
| which might affect the integrity of what you are about to commit. |
| Resolve conflicts. Test again, run integrity checkers (for example, |
| check for broken hypertext links, ensure your code compiles, |
| and so on).</p> |
| </li> |
| <li> |
| <p class="Para">Commit. Now that you are confident that your changes |
| are well integrated with the latest branch contents, commit your |
| changes to the branch. To be prudent, you may repeat the previous |
| step if there are new incoming changes. |
| </p> |
| </li> |
| |
| </ol> |
| </li> |
| |
| </ol> |
| |
| <p class="Para">Of course this is an <i>ideal</i> work flow. Under certain |
| conditions you may be confident that the incoming changes do not affect |
| you and choose to commit without updating. However, in general team |
| members should make an effort to follow a flow similar to the above in |
| order to ensure that the branch integrity is not accidentally compromised. |
| </p> |
| |
| <p class="Para">You can find more information on CVS at <a |
| href="https://directory.fsf.org/wiki/CVS" class="URL" target="_blank">https://directory.fsf.org/wiki/CVS</a>. |
| </p> |
| </div> |
| |
| <p><img border="0" src="../images/ngrelc.png" alt="Related concepts" > |
| <br><a href="concepts-27c.htm">CVS Repositories</a> |
| <br><a href="concepts-27b.htm">Branches</a> |
| <br><a href="concepts-27.htm">Versions</a> |
| <br><a href="concepts-30.htm">Synchronizing with a CVS repository</a> |
| </p> |
| |
| <p><img border="0" src="../images/ngrelt.png" alt="Related tasks" > |
| <a href="../tasks/tasks-92.htm"><br> |
| Creating a CVS repository location</a><a |
| href="../tasks/tasks-96.htm"><br> |
| Checking out a project from a CVS repository</a> <a |
| href="../tasks/tasks-103.htm"><br> |
| Replacing resources in the Workbench</a><a |
| href="../tasks/tasks-117.htm"><br> |
| Sharing a new project using CVS</a><a href="../tasks/tasks-115.htm"><br> |
| Synchronizing with the repository</a><a |
| href="../tasks/tasks-113.htm"><br> |
| Updating</a><a href="../tasks/tasks-113b.htm"><br> |
| Resolving conflicts </a><a href="../tasks/tasks-100b.htm"><br> |
| Merging from a branch</a><a href="../tasks/tasks-114.htm"><br> |
| Committing</a> |
| </p> |
| |
| <p><img border="0" src="../images/ngrelr.png" alt="Related reference" |
| > |
| <br><a href="../reference/ref-47.htm">CVS</a> |
| </p> |
| |
| |
| |
| </body> |
| </html> |
