Centralized Version Control

rcs kept its repository of history information in the “live” working directories.

• Each directory of a project had a separate repository.

• Sharing among team members relied on the rather limited Unix protection scheme.

Centralized version control systems keep a project repository in a location separate from the programmer’s work area.

• Allows one repository to track a project’s entire directory tree

• Encourages/requires use of a network-based sharing scheme

  • Allowing therefore a more distributed work effort

1 CVS

• Based on rcs

  • Many of the concepts and commands are similar

• Uses a centralized store

  • can be on local or remote machine

1.1 History

• Check-in and check-out are similar to rcs

  • No locks, however

• By default, scope of commands is an entire directory tree

cvs checkout projectRootDir 

makes a copy of projectRootDir in the working directory, checking out the most recent version of everything in the project.

Similarly,

cd projectRootDir 
cvs commit -m "Added unit tests" 

checks in any changes from the working directory on down.

find . -type f -exec rcsDoSomething {} \;

Where’s the Repository?

The earlier commands presume that we have, somehow, already established a connection with the repository.

• In practice this is either done via earlier steps or added as additional options to individual commands

Local CVS Repositories

If the repository is on a local file file system,

• you can specify it via -d:

cvs -d /usr/local/cvsroot checkout myProject/projectRootDir

or record this info in an environment variable:

setenv CVSROOT /usr/local/cvsroot
cvs checkout myProject/projectRootDir

Remote Repositories

The same techniques (-d, CVSROOT) can be used to specify remote repositories.

• Instead of simply specifying the path to the repository, give

  [:method:][[user][:password]@]hostname[:[port]]/path/to/repository
  
  

  • Specifying the password in this way is a really bad idea

• Usually, use

  cvs login
  
  

  to open a session (rather than get prompted for a password on every command).

Connection method: pserver

• The pserver method is a built-in network connection method with password control.

  • Port 2401

• Falling out of favor

pserver Exmaple

sirius:~/temp/tmp> setenv CVSROOT :pserver:zeil@cvs.cs.odu.edu:/home/cvs/dlib
sirius:~/temp/tmp> cvs login
Logging in to :pserver:zeil@cvs.cs.odu.edu:2401/home/cvs/dlib
CVS password: *****
sirius:~/temp/tmp> cvs checkout AlgAE
cvs checkout: Updating AlgAE
U AlgAE/.project
U AlgAE/AlgAE_layout.odg
U AlgAE/LICENSE.txt
U AlgAE/README.txt
U AlgAE/build.xml
U AlgAE/buttons.gif
U AlgAE/buttons.odg
U AlgAE/jhbasic.jar
U AlgAE/junit-4.10.jar
cvs checkout: Updating AlgAE/AlgAE_screenshot.png
   ⋮
sirius:~/temp/tmp> ls -ld AlgAE
drwxrwxr-x 11 zeil faculty 1024 Feb 21 13:39 AlgAE/

ssh Connections

If you have ssh access to the machine running the CVS server, you can do

sirius:~/temp/tmp> setenv CVSROOT :extssh:zeil@cvs.cs.odu.edu:/home/cvs/dlib
sirius:~/temp/tmp> cvs checkout AlgAE
The authenticity of host 'cvs.cs.odu.edu (128.82.4.233)' can't be established.
RSA key fingerprint 
   ⋮
Password: 

The History Commands

• checkout: gets an initial copy of what’s on the server

• update: checks to see if something newer than a local file copy is on the server, and if so, replaces the local copy by the remote one

• commit: sends any local files that are newer than the server copy to the server as new revisions

• add: places files that are not currently being tracked by CVS under version control

  • does not affect the server until committed

• import: places a directory tree under version control

• release: detaches the directory from the CVS server (if no files need to be committed)