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.

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`
  

  The method is a network protocol.

  • CVS provided its own network protocol, pserver, for this purpose.
  • Eventually, ssh was supported and became the more common choice.

pserver Example

sirius:~/temp/tmp> setenv CVSROOT :extssh:zeil@cvs.cs.odu.edu:/home/cvs/dlib
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/

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)

1.2 Exploration

Branches

• Same as rcs

2: Right-click on the HEAD project and select “Team ⇒ Merge … ”.

• You will be asked what branch you want to merge with. Select the appropriate branch to be merged into HEAD.
• You will be asked to supply the common base version from which the branch was split - usually Eclipse will guess this correctly.
• You can also decide whether to have CVS automatically make any non-conflicting changes or to let you preview them.
• No matter what choice you make here, conflicts will still be presented to you for resolution.

3: CVS will compare the checked-in copy of the branch against the files in your local HEAD project.

• You should see the familiar Synchronization view, in which you can preview changes and resolve conflicts.
• The goal of this process is to leave you with a local copy of all the desired changes.

  This is not a commit of the merged changes to the HEAD branch.

4: Having resolved all changes, you now have a local copy of the project, associated with the HEAD branch in CVS, with a merged copy of code from the former HEAD and from the other branch.

• It has not been committed to the repository yet.
• You can test it out, and then decide whether to commit the changes into the HEAD.

1.3 Collaboration

Resolving Conflicts

During synchronization, changes are categorized as

• Incoming: files that you have not edited your local copy (since it was last synchronized with the repository) but for which a revision has since been checked in.

These presumably need to be updated.

• Outgoing: files that you have changed (since it was last synchronized with the repository) and for which no revisions have been checked in.

These presumably need to be committed.

• Conflicts: Files that have been changed in your local directory and that have had revisions checked in to the repository.

These presumably need to be merged

Conflict Editors

Many IDEs provide special side-by-side editors for reviewing and resolving conflicts.

This, for example, is the Eclipse editor

• It allows you to view the differences between the two versions and decide whether

  • to keep the local version of each block of changed lines or
  • to replace by the repository’s version.

• You can save the merged file and then “Mark as Merged”, which moves it from the “Conflicts” status to “Outgoing”

• Or you can “Override and Update”, which indicates that you are abandoning your local changes and changing the file’s status to “Incoming”

2 Subversion

Subversion

Subversion (a.k.a. svn) is a later version control system based on the same centralized model as CVS.

• For the most part, working with it is not all that different from CVS.

• It rose to popularity in the open source community in part because of some useful tools for making read-only versions available on the web.

  • In fairness, this is not due to any particular strength of Subversion.
  Such tools could easily be targeted at CVS as well.

2.1 History

Differences between CVS and Subversion w.r.t. history:

• Subversion uses simpler revision numbers

• Subversion tracks file and directory creation, deletion, renaming

2.2 Exploration

2.2.1 Subversion Doesn’t Understand Branches …

Subversion does not implement a distinct mechanism for branching.

2.2 Exploration

2.2.1 Subversion Doesn’t Understand Branches …

Subversion does not implement a distinct mechanism for branching.

• Each revision (and each checked-out local copy) “knows” its parent revision number.

2.2 Exploration

2.2.1 Subversion Doesn’t Understand Branches …

Subversion does not implement a distinct mechanism for branching.

• Each revision (and each checked-out local copy) “knows” its parent revision number.

• Revisions can be checked out into distinct local directories from where their parents were located.

2.2 Exploration

… but it Does Branches Anyway

 

A typical subversion repository looks like this.

• “Branches” are kept in a separate directory from the trunk.

  • But a checked-out version of a branch “knows” which revision it came from
    • whether that revision is on the trunk or on the branch

• “Merging” is a general operation between revisions

  • So it can be done as a regular merge to adopt changes made in the branch as part of the trunk
  • or as a “sync merge” to add revisions from the trunk to the branch

Is This an Improvement?

Is This an Improvement?

Is This an Improvement?

Is This an Improvement?

2.3 Collaboration

No real differences between CVS and SVN