CMU TMR Rosetta Stone
The Big Picture
Each developer checks out one or more work areas, which are simply copies
of the source tree augmented by some version tracking info. These files
are edited as normal, may be compiled, etc. When stuff is working,
you "commit" your changes, which copies them back into the repository.
Nothing you do has any affect on any other developers until you commit
your changes.
Work areas may be in AFS or on the local disk. My current plan is
that I'll develop major changes in my AFS working area
project/tmr/checkout/ram/src, but do compiling in d:\users\ram\src on
Jenna. You can also make changes in the working area in Jenna and
check them in from there. Other developers should have their own
working areas on Jenna, and in AFS if they want to work in AFS.
In addition to keeping track of which files are changed and copying
them to and from the repository, cvs also semi-automatically merges
divergent versions, and maintains a history of all versions of
the code that have ever been checked in. Version merging is implicit
in the "cvs update" command below. I don't discuss the history features.
Initial Configuration
Currently CVS is only configured to be used from machines with AFS
access (you only need access to check out or in, so operation off the
net is possible.)
First, you must tell CVS where the repository is located (e.g. in your unix
".login"):
setenv CVSROOT /afs/cs.cmu.edu/project/tmr/cvsroot
If you log in as administrator on Jenna, this variable is already set up (to a
slightly different value.)
Creating a Work Area
In order to get a CVS tree to edit in, cd to the place where you want
the "src/" directory to be, and do
"cvs co src".
You can then edit files as you please.
Updating
To incorporate newly checked in changes into your work area, cd to "src/" and
do
"cvs update"
. When you update, CVS prints each modified filename prefixed
with a
cryptic single character code
indicating how updating was done. If you have not-checked-in changes that
overlap with some new changes, the character is "C". In the case of a
conflict, the file is modified with diff-like garbage containing all
relevant versions, and you must fix it manually in an editor.
See the
conflict example
.
If there are changes to a file, but on distinct lines, CVS will
use an "M" flag, and automatically merge the two files. This almost
almost always does the right thing, and when it doesn't, the file
usually fails to compile.
Adding New Files
CVS requires an explicit
"cvs add"
command when you add a new file to the tree. If you have a file
randomfile.cc in your work area which has not been added,
update and commit will print "?randomfile.cc" to remind you to
either add or delete this file. To add a new file to the repository,
just create the file in the appropriate directory, cd to that
directory and do "cvs add randomfile.cc". This add will take effect
when you next commit.
Committing changes to the repository
When you believe you have a consistent set of changes, you should
check them in. Cd to "src/" or some subdirectory that contains all
the changes. do a "cvs diff" to generate diffs of all the changes you
have made, and check that you really do want to check in those changes.
Then do "cvs commit" to check in your changes. You will
be asked for a change log message for each directory containing
changed files. Refer back to the diff to remind yourself what you
changed and why.
If you go to commit, and someone else has checked in changes that you
haven't updated, then the commit will fail, and you must update.
Home
| Mail to CMU TMR-members