Java Reference
In-Depth Information
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.
TIP
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
