Mr. Know-It-All has the answers to even the really tough questions.
I want to get involved with Open Source development. It seems that all the Open Source projects use CVS. I've read the Cederqvist, but I'm a bit confused. How about a CVS for Dummies?
OK, if you insist.
For those that have not read the Cederqvist.
CVS is the Concurrent Versions System version control tool.
Its goal is to allow multiple developers to work on the same code base
with a minimum number of conflicts and a maximum amount of productivity.
Like other source code control tools, CVS is Repository based and
uses the check out, check in model.
The Repository contains a complete record of all changes to the code base.
The Repository can be local or remote.
For remote Repositories, CVS supports several client/server access methods.
A developer checks out a copy of the code base to a local work area.
CVS calls this work area a Sandbox.
The developer checks in the changes from the Sandbox to the Repository.
CVS calls this committing the changes.
The Sandbox is a directory tree.
Some of the directories will contain source code.
Others are owned by CVS and contain control files.
The CVS owned directories are named CVS and CVSROOT.
CVS differs from most other source code control systems in that
files are not locked when a developer checks them out.
This means a second developer can check out a
file after the first developer, make changes and commit the changes
the Repository before the first developer.
This means that the first developer is now working with an older version
of the source code.
CVS solves this problem for the first developer by automatically merging
Repository changes into the Sandbox, when requested.
If there are conflicting changes, they will be flagged.
In practice, conflicting changes do not occur all that often.
Select a CVS Client.
There are a several OS/2 CVS clients available.
Mr. Know-It-All uses
Concurrent Versions System (CVS) 220.127.116.11 (client/server)
which seems to work well.
There is also the older
Concurrent Versions System (CVS) 1.11 (client/server)
Install the CVS Client.
Installing the CVS client is straightforward.
To summarize the README:
- Unzip the zip file to a work directory, preserving paths.
- Move to contents of the bin directory to a directory in the PATH.
- Move to contents of the book directory to a directory in BOOKSHELF.
Run the install.cmd script from the installation directory
to create Desktop objects for the INF files.
Delete the script after you have run it.
- If you use the info reader, move to contents of the info directory to your info directory and
add an entry for the CVS info files to the dir file.
- If you use the man reader, move to contents of the man directory to your man1 directory.
- You can ignore the contents of the scripts directory for now.
The scripts are for server side features.
The folks from Netlabs also provide a nice CVS front-end
This front-end supplies a set of WPS objects that make it easy to
access to the CVS Repositories for the various Netlabs projects.
First Time Setup.
If you haven't already do so, define a home directory.
From the command line:
to CONFIG.SYS so that the setting is preserved across reboots.
The example uses drive D:, but this can be any convenient drive.
Create the file D:\home\.cvsrc containing:
The -z3 applies to all commands.
The level 3 compression reduces data transfer time without excessive computational overhead.
The -d applies to just the update command.
The option tells CVS to automatically create new directories in the Sandbox as needed.
I don't know why this is not the built-in default.
CVS creates temporary files and expects TMP to be defined.
This should have happened when you installed Warp.
If you point TMP to a RAM disk and don't have a lot of RAM,
you may have problems with large Repositories.
Creating a New Sandbox
The examples that follow refer to the excellent XWorkPlace project.
The process for other projects is similar.
Create the Sandbox directory with:
Determine the CVSROOT value and login password.
These should be documented at the project website.
website states that the CVSROOT value is:
and the password is:
The CVSROOT value defines the access method, the user name and the
The pserver access method and user name are typical for Repositories that provide read only access.
Point at the Repository with the command:
Once the Sandbox is populated, the Repository location is recorded in the
Sandbox and the CVSROOT environment variable will be ignored for most commands.
Log in to the Repository with the command:
Enter the password when prompted.
You only need to log in once for each Repository you access.
CVS records the login password in d:\home\.cvspass.
Notice that you log in to a Repository not a project.
Although not the case for Netlabs projects,
a Repository may contain many projects.
Do the first time checkout to populate the Sandbox with the command:
cvs co .
where co is an abbreviation for checkout.
That's a period after the co and it is required.
For the checkout command, the period represents the default module, not the current directory.
With CVS, you check out modules, not directories.
Modules allow the Repository organization to differ
from the Sandbox organization.
Usually a module represents a single directory tree in the Repository, but
this is may not be the case for complex projects that have grown over time.
Many MB later you will have a Sandbox populated with the XWorkPlace code base.
Once you have populated the Sandbox, it's best to think
in terms of directories and forget about modules.
When working with an existing Sandbox,
the commands take directory or file arguments.
Also, most CVS commands are recursive by default.
A single command will process all the subdirectories
in the Sandbox.
After you have made some changes, you might ask yourself
what did I do?
You can review your changes with command:
cvs -q di
where di is an abbreviation for diff.
CVS will recurse through the directory tree and list the differences
for each modified file.
It's usually a good idea to pipe the diff output to less or redirect it to a temporary file.
Updating the Sandbox
After you have played in your Sandbox a while, you will
probably want to bring your Sandbox into sync with the Repository.
Update your Sandbox with the command:
cvs -q up
where up is an abbreviation for update.
CVS will recurse through the directory tree and update the Sandbox files as needed.
Each modified file will be listed along with a action code where:
U means CVS replaced a file you did not change with a newer version.
P means CVS patched a file you did not change to a newer version.
The effect is the same as an update. It just happens faster.
A means you added the file with cvs add, but have not committed the change.
R means you removed the file with cvs remove, but have not committed the change.
M means you have modified the file.
If the Repository is also modified, CVS will display an additional message
when it merges the Repository changes.
C means you have modified the file and there were changes in the Repository
and that conflicts were detected during the merge.
You will need to edit the file and resolve the conflicts.
The conflicts are marked so you can find them.
? means CVS found a file in your Sandbox that is not in the Repository and that is
not configured to be ignored.
Updating the Repository
Eventually you may be given write access to a Repository and you will
want to commit your changes to the Repository.
Commit your changes with the command:
cvs ci -m"Added foobar recovery support"
where ci is an abbreviation for commit.
CVS will recurse through the directory tree and update the Repository as needed.
Each file modified will be listed along with the new version number.
Some Handy Commands
Like all applications with a unix heritage, the cvs command has a
multitude of options and switches.
Here are a few obvious and not so obvious combinations that you may find useful.
lists an overview of the available command line help options.
cvs up -?
lists the options available for the update command.
cvs co -c
lists the content of the modules file.
cvs -q up -l Changelog
quickly updates just the Changelog file.
cvs -nq up
does everything an update would do without changing any files
in the Sandbox.
cvs -nq ci -m"Testing"
does everything an check in would do without changing any files
in the Repository.
There are a vast number of CVS references on the web.
The core reference is
Version Management with CVS.
Open Source Development with CVS
does a good job of explaining why CVS works the way it does.
Of course, a visit to
The Home of CVS
is always a good plan.
Curious or in doubt, you can ask
OS/2 is his specialty and sharing solutions is his passion
Mr. Know-It-All lives in Southern California.
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2003 the Southern California OS/2 User Group. ALL RIGHTS
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.