4.2 Understanding CVS
CVS is an
source project; it started life as a set of Unix shell scripts in 1986 and came into its own with dedicated software in 1989. Support for CVS is available on many operating systems todayUnix, Linux, Windows, and others. For the full CVS story, take a look at http://www.cvshome.org.
The idea behind CVS, as with any repository software, is to manage and record changes to source code. In fact, there are many types of repository software available, and some are more powerful than CVS, but CVS is in the most widespread use (perhaps because you can get it for free).
In CVS, a
is the basic equivalent of an Eclipse project. Modules are represented by directories in CVS. Standard projects
are collections of
The files you share are stored in the CVS
. When you retrieve a file from the repository, you
check the file out
. After you've modified the file, you
the changes to check it back in and send those changes to the repository. If you want to refresh your own copy of a file, you
it from the repository.
In general, there are two models for source code repositories:
Only one developer can check out a particular file at onceafter the file is checked out, the file is locked. It's possible for someone else to check out read-only copies of the file, but not to change it. Access is sequential.
Developers can check out and modify files
. When you commit changed files, the repository software
your changes automatically. If it can't do that by itself, it'll notify you that you have to resolve the issue yourself. Access is random.
By default, CVS supports optimistic lockingalthough some CVS software also supports pessimistic locking. We'll be using optimistic locking here, which is what Eclipse supports.
Because each file needs to be kept track of, CVS gives each file a version number automatically. Each time a file is committed, its version number is incremented. When you first commit a file, its version number is 1.1; the
time, it's 1.2, and so on (this can depend on your CVS server; some will start with 1.0). When you commit files to the repository, they'll get a new version number automatically. We'll see these version
in the various views you work with when using source control.
When you update a file from the repository, your local version of the file is not overridden. Instead, Eclipse will merge your local file and the one in the CVS repository. If there are conflicts, the conflicting lines will be
with special CVS markup indicating potential problems. You get the chance to modify your code to handle any conflicts that occurred during the merge operation, after which you can commit your new version of the code. Usually, updating goes smoothly,
if each developer working on the project has her own set area to work in, but sometimes you've got to
time resolving the conflicts that CVS points out to you manually.
CVS also supports development
. The main development stream of a project is called the head, and CVS has a special tag
that corresponds to that stream. Branches are forks from the head, and, in a branch, you can make changes that are independent of the main development stream, such as when you want to work on a beta version of your project. You tag a branch with a name, and CVS will keep track of the branches using their
. We'll see how all this works later in this chapter.