Introduction

Professional developers frequently work in teams, and Eclipse is up to the task. Eclipse supports the Concurrent Versions System (CVS) for this purpose. If you're working in a team, you have to coordinate your development work with others to avoid conflicts. You're all sharing the same code, which means your work of genius might be destroyed unintentionally by someone else's thoughtless efforts.

Source control precludes those kinds of problems because it controls access to shared code in a well-defined way. Besides controlling access to code, source control maintains a history of changes so that you can restore the code from earlier versions. Because it maintains a history of your code, not only can you restore code against earlier versions, but you can also compare the current code to earlier versions to see the differences at a glance.

Like much else in the Java world, CVS is an open source project. CVS first appeared in 1986, when it was a set of Unix shell scripts; it wasn't until 1989 that dedicated CVS software first appeared. Today, CVS is available on many operating systems across the board, from Unix and Linux to Windows.

For details on CVS, take a look at http://www.cvshome.org.

The CVS repository is where developers store code files to be shared. To retrieve a file from the repository, you check that file out of the repository. When you want to store your newly changed version of the file, you commit it to the repository. Refreshing your copy of the code from the repository is called updating it.

CVS also has slightly different terminology than Eclipse; what's a project to Eclipse is a module to CVS. Each module gets its own directory in the repository, making it easier to separate modules. Standard projects also are called physical modules, while logical or virtual modules are collections of related resources.

How many copies of your code are available to be checked out at once? That depends on which repository model you use. Here are the options:

Pessimistic locking

Sequential access. With this type of locking, only one developer can check out a file at a time. When 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 the original. Access is sequential.

Optimistic locking

Random access. With this type of locking, developers can check out and modify files freely. When you commit changed files, the repository software merges your changes automatically. If the merge operation has issues, the software will flag them and ask you to resolve the problems.

CVS uses optimistic locking by default (some CVS software also supports pessimistic locking). We'll be using optimistic locking here, which is what Eclipse supports. You use a CVS server to handle the actual file manipulation, as we'll do in this chapter.

CVS also automatically assigns a version number to each file when it's committed. When you first commit a file, it's version 1.1 (1.0 on some CVS installations). The next time, the version number is 1.2, and so on. When you update your code locally, Eclipse doesn't just overwrite your local version of a file. Instead, it merges the changes with your local file in an intelligent way. If conflicts exist, it'll insert special CVS markup to make the conflicting lines stand out, and those conflicts will have to be handled before running the code. Usually updates are smooth, but if there are a lot of conflicts because there's been a lot of work on the file or you haven't updated in some time, it can take a while to unravel.

CVS also enables you to support multiple development streams, called branches, in the same module. The main development stream in a module is called the head, and branches are forks that can diverge from that main stream. For example, a branch can represent a beta version of the project, or some new capability you're adding to your code that you want to test first.