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