CSC223 2004F, Class 11: Access and Version Control with CVS

Admin:
* EBoards still a good idea?
* Questions on the homework?  Use same groups.
* Yet another "no time" weekend for SamR.
* Where are EvanCase and SamTang and LuisZuletaBenavides and ChaseMartyn?
  * Theory: Evan would rather not take a quiz and get a 0 than take a quiz.
  * Mishearing: SamTang isn't here because he hates the class.
  * Luis was just late.
  * Chase is chasing something.

Overview:
* Background
  * Issues in project management
  * Philosophy of Unix tools
  * Project management in traditional Unix
* CVS Philosophy (or Philosophies)
* CVS Basics

/Issues in Project Management/

* What problems come up when you try to work with other people?
  * People are confused about what they are supposed to do. [Use UML to describe the components of the project.]
    * Communication of goals
  * Kitten death.  Forced sterilization of parents.
  * Inappropriate changes to code.  *
    * And keeping track of them.
    * And merging them.
  * Different coding styles.  [Agree upon a coding style or have a "company style".]
  * Different programming practices. [Agree upon a practice: XP, in our case.]
  * Strange ways of keeping track of "current" version *
    * Email it to everybody
    * Shared account
  * Keeping track of the difference between the "experimental" and "currently correct" version. *
  * Scumbag partners 
    * Don't do their share
    * Insist on doing everything
* These problems get worse when you get larger projects
* Programmers have been developing tools to deal with them for years.

/The Unix Philosophy/

* Big tools are bad.  Build small tools that do their jobs correctly and provide system infrastructure to combine them.
* Better for implementers
  * Easier to fix something when it goes wrong.  (Ship a replacement for a small product rather than a big one.)
  * Allows designers to focus on the small components and make them "really nice".  
  * Working on the "free software" model, a single programmer can build each tool.  Fewer problems like those mentioned above.
* Better for users (that is, programmers using the tools)
  * Less excess baggage.
  * Don't need to learn as much ... only the tools you need.
  * Can choose the combination of tools that's best for you.
  * Smart programmers can combine the tools in new ways.
    sed -e 's/[ \t]/\n' | sort -u | "remove all words in /usr/dict"
* Unix system management tools tend to focus on one or two key tasks.
* What's wrong with the "separate tools" philosophy?
  * "Dependency heck".  
  * Don't necessarily integrate well.
  * Harder to incorporate a design philosophy in "the tool".

/The original Unix system management tools: SCCS and RCS/

* SCCS: Source Code Control System
* RCS: Revision Control System  <- Sam prefers
* Key goals:
  * File sharing between collaborating programmers
  * Version control
    * Old versions of files are still available (in case you delete important chunks)
    * Way to distinguish "current usable version" from "development version"
    * Encourages programmers to document changes.
* Central model: Variant of a "Library"
  * Only one person can "check out" a file at a time (for modification).
  * Anyone can access the version at the time of checkout for reading.
* No real notification when a file changes.
  * Programmer responsible for saying "I want the latest version"
* Easy commands: co file, ci file

/The arrival of CVS/

* Problem: RCS and SCCS designed for many people working on one computer
  * Work fine with shared filesystems.
  * Don't work fine when different programmers are at different sites.
* Problem: Evidence shows that programmers forget to check in their changed files or at least take too long.
* Problem: Need a better way to distribute code on the Internet.
* The solution: CVS, Concurrent Versioning System
  * Provides Internet-based distribution.
  * Handles "multiple programmer" issue by crossing fingers
* Some problems handled by an ethos of design similar to XP.

/Using CVS/

* CVS files are in a "repository" (on the Internet or on the local filesystem).
* Within each repository are one or more "projects".
* To get access to an existing project
	% cvs -d REPOSITORY checkout PROJECT
* Once you've made a copy of the project, have fun editing/changing.
* Ethos: Regularly type "cvs update"
* When you've made a copy of a file ready for others to use, say 
	% cvs commit FILENAME
* When you want to add a file to the project, use
	% cvs add FILENAME
	% cvs commit
* Morals:
  * Use cvs
  * Execute 'cvs update' whenever you start programming
  * Execute 'cvs update' before commit changes.
  * Try to use 'cvs commit' each session, but only for compilable/working code.