4.2 Understanding CVS
CVS is an open 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 today�Unix, 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 module is the
basic equivalent of an Eclipse project. Modules are represented by
directories in CVS. Standard projects correspond to
physical modules, while
logical or virtual
modules are collections of related resources.
The files you share are stored in the CVS
repository. When you retrieve a file from the
repository, you check the file out. After
you've modified the file, you commit
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
update it from the repository.
In general, there are two models for source code repositories:
- Pessimistic locking
Only one developer can check out a particular file at
once�after 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.
- Optimistic locking
Developers can check out and modify files freely. When you commit
changed files, the repository software merges
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 locking�although 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 next 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 numbers 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 marked 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, especially if each developer working on the project has her
own set area to work in, but sometimes you've got to
spend time resolving the conflicts that CVS points out to you
manually.
CVS also supports
development branches. The main development
stream of a project is called the head, and CVS has a special tag
name called HEAD 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 names. We'll see how all this works later in
this chapter.
|
No comments:
Post a Comment