Now, the user x can edit the files, add new files, commit changes, or build the application just
like the person that created the initial version.
To bring a checked out version up to date with the current state of the repository, the cvs
update command is used from the project source directory:
$ cd ~/myApp
$ cvs update d
It is usually helpful to coordinate among the developers and decide who should work on which
files to avoid two developers checking out the same file and working on it simultaneously (files
that are checked out are not locked by CVS). Although CVS has merging capabilities to bring
different versions together, this does not work very well. It is also recommended to commit
changes and run cvs update regularly to avoid conflicts that can occur when developers use
older versions of files.
CVS offers many other features. Please refer to the resources given in Section 3.2.5 for
126.96.36.199 Scalability of the Presented Development Approach
The presented approach installed Tomcat and the source code repository on one central server.
Building and deployment of the application was also done on this server. This works well for
smaller development teams of around three team members. The developers can access the
central server easily via Telnet, and have their own local copies of the source code in their
However, concentrating the development on a single server has disadvantages. Assuming that
all developers use the same deployment directory for their builds and compile their source code
on the same system, a larger number would cause too much interference among them.
Stopping and restarting Tomcat, which has to be done occasionally to re load the application, as
well as limited system resources slow down development as the number of developers
The easiest and most efficient way of addressing these issues is to provide each team member
with his/her own machine running its own local instance of Tomcat. Other options are available
as well, which will be introduced in Section 5.2.