As the class goes on, we're going to release multiple versions of JOS.
Here's how to use CVS (the
Concurrent Versions System, a source code management system) to keep up to
date with our code base. There are many other ways, of course, including
Our CVS instructions are based in part on "Tracking
Third-Party Sources", part of the useful CVS manual. On most Unix
systems you can access this manual with
The two fundamental CVS concepts are a repository and working copies. The repository holds a permanent historical record of changes made to your project files. A working copy is a snapshot of the project files; only working copies are directly editable. To make a change to a project, you check out the project, make your change to that working copy, and then commit your changes. This adds your changes to the repository, so that other people can see them.
Creating a Repository
First, then, we need to create a repository. We'll make a remote repository accessible over ssh, so that everyone on your team can access it. Tell CVS that you plan to use ssh to access remote repositories:
bash-type shells: tcsh-type shells: % export CVS_RSH=ssh % setenv CVS_RSH ssh
You'll probably want to add this to your
cvs -z5 update -P -d diff -u
These options tell CVS to compress network traffic, which can make
things a lot faster (
Choose a computer system that everyone on your team can log in to over
ssh, and choose a directory to hold your repository. Good
directory choices might be someone's
% ssh fun.cs.ucla.edu Last login: ... Welcome to fun.cs.ucla.edu! % mkdir /home/jos/cvsroot
We now need to make sure that everyone on your team can access the
directory. Hopefully, everyone is part of the same Unix group, like
% chgrp josheads /home/jos/cvsroot % chown g+rws /home/jos/cvsroot # The 's' means subdirectories will get group josheads automatically.
(If there's no shared group, you'll have to make the repository
world-writable.) Finally, the
% cvs -d fun.cs.ucla.edu:/home/jos/cvsroot init
Now we have an empty repository; our next step is to add JOS. Download
% tar xzf jos.tar.gz # or 'gzcat jos.tar.gz | tar xf -' % cd jos % cvs -d fun.cs.ucla.edu:/home/jos/cvsroot import \ -ko -m 'Initial checkin' jos-rks JOSDIST REL_1
This will import JOS into the repository, under the module name
Now it's easy to get a working copy:
% cd ~ % cvs -d fun.cs.ucla.edu:/home/jos/cvsroot co jos-rks % ls ~/jos-rks CODING GNUmakefile conf grade.sh kern mergedep.pl CVS boot fs inc lib user
Finally, here's how to merge in changes from a new
% cd ~/jos-rks % cvs log -rJOSDIST. -h GNUmakefile RCS file: /home/jos/cvsroot/jos-rks/GNUmakefile,v Working file: GNUmakefile head: 1.1 branch: 1.1.1 locks: strict access list: symbolic names: REL_2: 18.104.22.168 REL_1: 22.214.171.124 JOSDIST: 1.1.1 keyword substitution: o total revisions: 2 =============================================================================
Now download the new
% tar xzf jos.tar.gz % cd jos % cvs -d fun.cs.ucla.edu:/home/jos/cvsroot import \ -ko -m 'new release' jos-rks JOSDIST REL_3 ...
If all goes well, the import will succeed completely, but you might see a message like this:
2 conflicts created by this import. Use the following command to help the merge: cvs checkout -jJOSDIST:yesterday -jJOSDIST jos-rks
This means you've locally modified some files that were also modified in
% cd ~ % ls jos-rks # Already a working directory there CODING GNUmakefile conf grade.sh kern mergedep.pl CVS boot fs inc lib user % cvs -d fun.cs.ucla.edu:/home/jos/cvsroot co -jREL_2 -jREL_3 jos-rks
The last command checks out the differences between the last two
% cd jos-rks % cvs up ... files modified between REL_2 and REL_3 will show up as 'M'odified ... ... if there are 'C'onflicts, resolve them by editing the relevant files ... % cvs ci -m 'merge changes from new jos.tar.gz release'
And you're all set.