Software Design (CSC-223 97F)
Outline of Class 11: RCS
- Feel free to email me suggestions on these outlines.
- The first Sunday evening dinner went very well. At least one
visitor seemed to take thirds on the main course. There are still
slots for the coming weeks (the 28th -- meet Michelle; the first
weekend in October -- vegetarian).
- A few of you asked about
- When evaluating someone's work, you should look at their code.
- When using their work, you should not look at their code.
- I've revised the assignment slightly. You can now use whichever
class provides the
main(), as long as you don't
use (or read) that routine.
- Any other questions?
- Yup, it's time for the second quiz
(only available during class time; if you missed class, come see me).
- But at least you can eat some cookies while you're working. (Aimee
gets an orange by special request.)
- On Wednesday, we'll spend a little time putting together project groups
and talking about projects. I will be assigning project groups, so
if there is someone you don't want to work with, let me know ASAP!
- Up to this point, much of the programming you've done has been one
person working alone, or a few people working in front of the same
- As you get to larger projects, you'll need systems to make it easier
for a group of people working together on one project, but separately
on the pieces, to work together.
- At the same time, you'll want to track changes to your software. Why?
- So that you can continue to work on an assignment, but give me
access to your current working version.
- So that you can easily undo any stupid changes you've made to
- So that you can remember what changes you made when.
- What features should a revision control/project management system
- Access by multiple users
- Access control, so that
- Only members of the project team can update files.
- Two members of the project team don't update the
- Versioning, so that you can keep track of what changes have
been made, and when.
- Ability to unify changes.
- RCS is one of the more popular systems for version control and
- It's been around a while, but is still relatively popular for Unix
- We won't cover all of the details.
- One member of your team will maintain the central RCS directory.
That member should create a parent directory and RCS directory for
each project (and yes, the name of the RCS directory should be
% mkdir CoolProject
% chmod go+rx CoolProject
% cd CoolProject
% mkdir RCS
% chmod g+rwx RCS
- Everyone else should make a directory for that project and then make
a symbolic link to the RCS directory from their project directory.
(The RCS maintainer may also want to do this.)
% mkdir CoolProject.Personal
% chmod go+rx CoolProject.Personal
% cd CoolProject.Personal
% ln -s ~rcsleader/CoolProject/RCS .
- After discussing the potential contents of that directory, the
RCS person should create frameworks of the individual files. I would
recommend taking advantage of RCS's ability to fill in fields.
* @version $Revision$ of $Date$
- The RCS person should then add the file and make it usable by everyone in
% rcs -i Class.java
% rcs -a person1,person2 Class.java
% rcs -L Class.java
- In order to modify a file, you must check out that file
from the RCS repository.
- The command for checking out files is
co (gotta love
those Unix(tm) shorthands).
- To prevent over people from modifying the file at the same time, you
must also lock the file.
- The typical command to check out and lock a file is
% co -l Class.java
- When you are done modifying your file, you must check it back in,
- At the same time, you will probably want to unlock the file.
% ci -u Class.java
RCS/Class.java,v <-- Class.java
new revision: n.m; previous revision: r.s
enter log message:
(terminate with ^D or single '.')
>> A short summary of the changes.
- I'd recommend that you indicate when your code is stable (that
is, it's safe for your colleagues to use it) using
% ci -u -sStab Class.java
- Eventually, you'll want to test your objects in conjunction with your
- This means that you'll need to check out the code files, but in such a
way that it's okay if your colleagues still modify the code files.
- If you don't provide
co with the
you can check out the file in read only mode.
- If you're using the
-sStab conventions, you can
check out the most recently working version of a piece of code.
% co -sStab Class.java
- There is no need to check in a file checked out in this way.