The private repository on warriors.eecs.umich.edu is meant to hold internal projects and papers where multiple people are collaborating in a central location (so you do not need to remember a different CVSROOT for each project). There is no anonymous access, so it is safe for things which should not be accessible by people outside the research group.
Currently there are several subdirectories already created:
The warriors CVS repository can be accessed by two methods: Direct file access if the client machine is a DCO machine or via SSH from any other machine on the Internet. Direct file access is faster and requires no password authentication, so it is preferred if available. For either method, you must be a member of the 'jcrew' group to access the repository.
NFS access only works if the client machine has a umich IP address and the
DCO password files and is running the NFS automounter. The CVSROOT for NFS
access is /n/warriors/var/cvs. You can either set this in your login
scripts if this is the only CVS repository you access, or you can specify it at
the command line with -d. If you chose the later, an alias might be
helpful (use wcvs instead of cvs when accessing the
repository):
setenv CVSROOT
/n/warriors/var/cvs
or
alias wcvs cvs -d
/n/warriors/var/cvs
SSH access works from any machine which has both ssh and cvs installed on them. The downside is that it opens a new SSH connection for every operation, so you have to type your password in a lot. There are ways around this if you are using a trusted machine for access, namely the use of an authorized_keys file and ssh keypair for authentication. In addition to setting CVSROOT, you need to set CVS_RSH for this method to work. Unlike CVSROOT, which doesn't need to be set after a module has been checked out (it's value is stored in the CVS subdirectory), if you forget to set CVS_RSH all cvs commands will fail with a host not responding error. I recommend adding CVS_RSH to your login files regardless of wether you decide to set CVSROOT or not.
Again, you can either set CVSROOT or specify it manually with -d.
The settings for the SSH access method are:
setenv CVS_RSH
ssh
setenv CVSROOT
:ext:username@warriors.eecs.umich.edu:/var/cvs
or
setenv
CVS_RSH ssh
alias wcvs cvs -d
:ext:username@warriors.eecs.umich.edu:/var/cvs
The defaults for several CVS commands are less than optimal (it won't
automatically detect a newly added directory for example). Placing the following
in ~/.cvsrc provides more reasonable defaults:
checkout
-P
update -d -P
diff -u -d -b -w
rrdiff -u
cvz -z3
Once you have set your CVSROOT (or aliased wcvs, in which case replace cvs
with wcvs below), you can check out a module. For example, to check out the
latest version of the FreeBSD DCO setup scripts you would run:
% cvs
checkout fbsd
cvs checkout: Updating fbsd
U fbsd/Makefile
U
fbsd/PKGS
U fbsd/README
cvs checkout: Updating
fbsd/bin
...
Once checked out, the created directory is self contained and contains within it CVS subdirectories that keep track of the module and repository, so you can change the root directories name, move it around, or change your CVSROOT and it will still work.
Once you have checked out a module, you have a working directory where you
can make changes to the files. You do not hold a lock on these files, so you do
not need to worry about preventing others from accessing them. CVS does not
automatically update your directory when others make changes, you have to use
the 'update' command to check for changes:
% cd
module
% cvs update
CVS lists each file in the
directory preceded by its status. "U" and "P" mean that you local copies of the
file were updated with newer versions from the repository. "C" means that it
tried updating your local version, but your changes caused conflicts (see
below). "M" means that your local copy of the file has been modified, but you
have not committed the changes yet. "A" means you have added the file to the
repository but not yet committed it the first time. "?" means the file in your
local directory is unknown to CVS. To add it, use "cvs add
file", and the next time you do a commit it will be sent to
the repository.
When you have made changes that you wish to commit to the repository (because
others need to see them, or because you would like a record of the file at this
state in case changes you are about to make do not work and you want to roll
back), you use the commit command. Before committing a file, you need to check
that the file you made your changes from was the same version as the latest in
the repository. CVS handles concurrent editing by forcing the committer of a
file to be working against the most recent revision when they commit a file. If
someone has checked a new version in between your last update and when you want
to commit, CVS will try to do a three-way merge between the revision you started
with, the current CVS revision, and your working revision. If it is successful
(the changes occurred in completely different parts of the file), you can then
commit your changes. If there are conflicts, CVS will save an unmodified copy of
your version of the file in .#file.vers, and mark the conflicts in your
local copy. Search for "<<<" and ">>>" to find the conflicts.
Once the conflicts are fixed, you can commit the file:
% cvs commit
file
Most of the CVS file commands work recursively on an entire directory if you don't specify any files to update/commit/diff/stat/info/etc. If you only want to work on a single file though, you can specify it and only that file will be committed or updated.
There are a couple of different ways to add to the repository. The easiest
way is to use the cvs import command. Import takes everything in the
current working directory and adds it as the module you specify on the
command line. Be careful to run this from within the directory you want to add,
not the directory above it. Import takes two mandatory tags, which you can just
set to modulename and "import". As an example, if I have a paper titled 'mirror'
that I would like to import into the repository so others can work on it, I
would do:
% cd ~/Papers/mirror_paper
cvs import
papers/idmaps-mirror idmaps-mirror import
This will create a new
module "papers/idmaps-mirror". The existing directory imported is not in
CVS. You need to check out the new module to begin working in CVS.
If you are starting from scratch, there is another way you can add a new
module. If what you want to add is a subdirectory of another module in the
repository (e.g. papers in the last example), you can just add a new directory
to the upper module:
% cvs checkout papers
cvs checkout: Updating
papers
...
% cd papers
% mkdir idmaps-mirror
% cvs add
idmaps-mirror
And a new, empty directory will have been added to the
repository. For directories at the root, it is easiest just to import.
To make it easy to find papers in the repository, there is a naming convention used. The module for a paper should be called "area-name" where currently area is one of "games", "idmaps", "mcast", "security", or "topology". name should be a brief one-word description of the paper.
Many papers evolve over time, with different versions getting submitted to
different conferences. Instead of creating a new module for each variation of a
paper, CVS tags should be used. A tag is an easy way to group the current
version of all files in a module under an easy to remember name for future
reference. To lay down a tag:
% cd papers/idmaps-mirror
% cvs tag
-R JSAC02
To switch from the currennt version of a module to a particular
tag, use the -r flag to update:
% cd
papers/idmaps-mirror
% cvs update -r JSAC02
Finally, to go from a
tagged version back to the current working version of a paper, use the
-A flag to update:
% cd papers/idmaps-mirror
% cvs update
-A
Sometimes it's convenient to be able to just check out a particular
subdirectory, like 'idmaps-mirror' instead of 'papers/idmaps-mirror'. This can
be accomplished through module aliases. To add a new alias for a module, you
need to edit the modules file in the special CVSROOT
module:
% cvs checkout CVSROOT
cd CVSROOT
vi modules # add a
new alias, use existing ones as an
example
# it's a
global namespace so keep that in mind
cvs checkin
cd ..
cvs release -d
CVSROOT # yes you want to delete it, you're done
Be careful when
editing modules, since it is parsed automatically by the module list
CGI.
Most of the common CVS commands have shortcuts you can use:
| Command | Shortcut |
| update | up |
| commit | ci |
| remove | rm |
| checkout | co |
CVSWeb provides a GUI interface to browsing the repository. Among its nicer
features is the ability to easily do diffs between various versions of a file
and present the output in a nice colored side-by-side comparison. To access
cvsweb you need a password. You create this password by connecting to tail and
adding yourself to the htpasswd file:
tail% sudo htpasswd
/usr/local/etc/apache/auth_db/warriors username
You can then access
CVSWeb from the link off the main Warriors home page, or by going directly to http://warriors.eecs.umich.edu/cvsweb/cvsweb.cgi.
This is not a secure connection, so don't use a password you use anywhere else.
This should be enough to get you started with our CVS setup. For more help with CVS, the MESH Advanced Unix Development Workshop, CVS Overview, CVS Manual, and CVS FAQ-O-Matic are good references. There is a hardcopy of the CVS Manual in 4316 if you want to borrow it.
| Eric CroninLast modified: Mon Apr 29 16:49:56 EDT 2002 |
|