< Zurück | Inhalt | Weiter >



As a noun, is a special label that you create to mark a milestone in your source repository; you can return to that milestone by checking out a copy of the source with that tag.

As a verb, refers to creating a tag in the source repository.

Once a repository has been set up for use by a project, each developer would check out a copy of the source. Thereafter, the typical sequence for a developer would be:

1. Edit.

2. Test.

3. Commit.

4. Go to step 1.


In some organizations, developers will commit and then test. Others will want to only commit changes that have been tested. Which order you choose is a policy decision by your project, not mandated by CVS.


We recommend that you test before committing because once you have com- mitted your changes, they become available to all others developers. The more people are working together on a project, the more important it is to keep the source base workable, that is, clean compiling at least, so others can keep working.

Sometimes the developer needs to do an update step before a commit. Such a step is used to integrate other developers’ changes into this developer’s source. Sometimes this goes smoothly; other times it needs some additional work.

A simple scenario might help explain these steps, too.

Two developers, Ti and Kwan, are working on project Doh. They already have a repository set up with all the source for project Doh. Each developer, on his/her own system, checks out a copy of the source (cvs checkout doh). Now let’s say that part of the source is a Java class file called Account.java and it has had several changes made already, so Account.java is now at version 1.7 in CVS.

Let’s say that Ti finds a bug in Account.java and makes a change to fix that problem. Ti checks in (commits) the changes to Account.java (cvs commit Account.java) so that the repository now contains Ti’s changes, which CVS keeps as version 1.8 of Account.java.

All this time Kwan has been busy modifying Account.java (e.g., adding a new method). Remember that Kwan is working from the 1.7 version. When

Kwan goes to commit his modified version of Account.java to the repository, he is notified that Account.java has been changed since his copy was checked out, and the commit attempt fails. So Kwan does an update which merges the

1.8 version of Account.java in with his modified 1.7 version. If all goes well, the resulting file will be a 1.8 version of Account.java which includes Kwan’s new changes in the right place(s). Kwan just commits this to the repository, and Account.java then stands at version 1.9.

Note that cautionary phrase “if all goes well.” The merge will work if Ti and Kwan have each modified different parts of the same file. If all Kwan did was add a new method, it would merge just fine. But what if they both make changes in the same region of the source file? It is up to the programmer to resolve such conflicts and commit the source once again.

In such a situation, CVS does what it can to help out. There is an example of a merge conflict later in this chapter. But such conflicts require human intervention.

Merging of conflicts is, undoubtedly, a very manual process, but you will be surprised by how infrequently you need to do this. Most changes will be merged clean with no manual intervention required. That’s probably because most often, when two or more programmers are modifying the same file, they are modifying different sections of it.

With merging, you have the ability to incorporate other developer’s changes into your version of the source without the fear of losing your changes. No one’s changes get lost, no one’s files get “stepped on.”