Team programming with CVS
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.
Optimistic team model
CVS provides two important features required for working in
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
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/.
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
Merging from a branch