/projects/instr/01au/cse401/cse401a
.
Currently (Thu Oct 25 14:50:34 PDT 2001), the groups are:
cse401a -who rrh,andrei cse401b -who nbs,ehsu cse401c -who ggreenle,kachan cse401d -who kevwitz,pryan cse401e -who crosetti,aquinn cse401f -who intaek,jasonkim cse401g -who nathanh,mamc cse401h -who luke,deborahf cse401i -who jaehoon,seokman cse401j -who lau273,mquinn cse401k -who bean,gpotts cse401l -who adeakin,tewfik cse401m -who joyceb,ltmann cse401n -who saboosh,martintj cse401o -who jlarsson,ajglover
This directory will be owned by one of the course staff, and have a group ownership of (say) cse401z. The directory will be group writable. Use this directory to hold files you need to share with your group-mates. Remember that files you create here need to be made "group readable" and/or "group writable", but should not have "world" access.
THIS PAGE IS NOT FULLY DEBUGGED (rrh, Thu Oct 25 14:55:25 PDT 2001)
It is highly recommended that you use CVS ("Concurrent Version System") to control concurrent development to the same software base. If you don't use CVS, then you risk having large portions of your work disappear when one of your partners writes over the same file you were working on.
If you haven't used CVS before, or even if you have, please take a look at ACM Chapter CVS introduction which was put together by the local student chapter of your professional society (ACM). Very briefly, using CVS involves registering all files in your project and then checking them out to use them, and checking them in when finished.
CVS is built on top of another tool called "RCS" (Revision Control System), but CVS is one better, in that you can have concurrent versions of the software checked out.
CVS is open source software, and has become the standard mechanism on LINUX systems for managing software. See the CVS Home Page .
Here's one simple way that you can set up your universe for using CVS for the cse401 project. I will assume that you are in group CSE401Z; use your own group name as appropriate.
Edit your ~/.mycshrc file. Put a line into that file that looks like:
setenv CVSROOT /projects/instr/01au/cse401/CSE401Z/repository
Log out. Log back in again (this forces the ~/.mycshrc file to be reread) Do:
printenv CVSROOTand check that this environment variable is set up as you intended. If it isn't, then make the same edit somewhere in your ~/.cshrc file. and try again.
Only ONE member of your group should do this step: Do:
cvs initThis will set up your repository. Check that the repository directory got created:
ls -l /projects/instr/01au/cse401/CSE401Z/repository
Only ONE member of your group should do this step. Start adding files to CVS. Let's assume that the original source code for the pl0 compiler that you are both are going to be working on is in a sub directory named pl0 in your home directory. Starting in the directory that contains the pl0 directory, do:
cvs co . # checks out an empty repository cvs add pl0 # adds your pl0 directory to CVSS cd pl0 cvs add *.c *.h *file *.0 # add individual files cvs add CREDITS TODO OVERVIEW README cvs commit # commits the original version of the files
The other member of the group should now do this (once), in his/her home directory:
mv pl0 my_original_pl0 cvs co . # should make a pl0 directory cd pl0
You now have the same copy of the pl0 source. The revision control information and "master copy" of the software is off in
/projects/instr/01au/cse401/CSE401Z/repositoryYou should NEVER have to edit anything in this directory! Do ALL of your work in your home pl0 directory, which is under CVS control.
You make some changes. You ensure your changes work. You are now ready to check in your changes. Do:
cvs update . # update your working copy with the repository ...edit to remove branch conflicts... (see below) make # ensure still compiles cvs diff . # review your changes (no side effects) ...edit/compile/use as necessary to fix problems... make # ensure still compiles cvs commit . # commit your changes (side effects on the repository)
If your partner checks some stuff in, you'll want to update your world with respect to his changes:
cvs update . # update your working copy with the repository ...edit to remove branch conflicts... (see below) makeYou should synchronize your work often, so that your world doesn't get too far apart from your partner's world.
In some circumstances, the changes you have made to your copy of the software are incompatible with those changes your partner has made and checked in. CVS will (usually) detect this situation, and flag the lines that are in conflict. (Your program won't compile any more, since the flags aren't legal C++!) The flagged lines look like:
>>>>> something or other ===== somethingelse or other <<<<<You'll have to examine the conflicts and decide which version is the appropriate version, or figure out how to combine one version (above the ===) with the other version (below the ===).
Conflicts come about because you both are working on the same lines of code at the same time, making lexically incompatible changes. You'll have to discuss the issues of "who is working on what" directly; there's no way the software can help here! Generally, if you are working on feature A, and your partner is working on feature B, and the code for the features is separated, you'll not have any problems. But, if you are working on feature A, editing a few dozen localized lines of code, and you partner is making some grand sweeping change, then your partner's work is likely to collide with your work. Actually, who collides with whom depends on who checks in first.
You should NEVER have a version of the compiler checked in that does not compile. Thanks to Nathan Herring for a preliminary version of this info.
401admin at cs.washington.edu