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.
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).
As team members produce new work, they share this work by committing those changes to the branch. Similarly, when they wish to get the latest available work, they update their local workspaces to the changes on the branch. Thus the branch is constantly changing, moving forward as team members submit new work.
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.
CVS provides two important features required for working in a team:
A history of the work submitted by the team
A way to coordinate and integrate this work
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.
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 optimistic because it is assumed that conflicts are rare.
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.
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.
The ideal work flow therefore is one in which the branch integrity is preserved.
The ideal work flow proceeds as follows:
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 Checkout (or Replace with > Latest from Repository if the projects already exist locally). This will overwrite your local resources with those from the branch.
Make changes. Work locally in your Workbench, creating new resources, modifying existing ones, saving locally as you go.
Synchronize. When you are ready to commit your work, synchronize with the repository.
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).
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.
Of course this is an ideal 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.
You can find more information on CVS at http://ximbiot.com/cvs/.
CVS Repositories
Branches
Versions
Synchronizing with a CVS repository
Creating a CVS repository location
Checking out a project from a CVS repository
Replacing resources in the Workbench
Sharing a new project using CVS
Synchronizing with the repository
Updating
Resolving conflicts
Merging from a branch
Committing
