Team programming with CVS

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.

Optimistic team model

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.

Recommended work flow

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.

Ideal flow enumerated

The ideal work flow proceeds as follows:

1. 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.

2. Make changes. Work locally in your Workbench, creating new resources, modifying existing ones, saving locally as you go.

3. Synchronize. When you are ready to commit your work, synchronize with the repository.

   1. 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).

   2. 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 https://ximbiot.com/cvs/.