Using version control for class submissions

There are a few of great reasons to use a version control system for student submission in a programming class. First, students typically do not get enough exposure to version control systems in school, but are likely to see heavy use of them after they graduate. Second, checking in intermediate versions makes it easier for students to work in multiple locations, and for the instructor or TA to get a copy of their recent code for questions during office hours. Third, enforcing incremental checkins provides a backup in case of accidental loss of work that can happen especially toward the end of a project. Finally, those same incremental checkins allow the instructor or TA to follow the development process during grading, which can both makie it more difficult to cheat by copying from classmates, and help in determining when partial credit might be merited.

CVS on AFS

A clone of a CVS repository has just the most recent versions of each file. The version history is entirely contained in the files of the central repository. The directory structure of that central repository exactly matches the directories of the checked-out copy, making it possible to have fine-grained read and write access control to subsets of the main repository, This makes it possible to have a single class-wide repository with controlled access to per-student subdirectories.

Creating the source code repositories for each student on the university's unix file system gives more control and does not require students to create an account with an external service. UMBC's unix servers use AFS, which allows very fine-grained per-directory access control, so it is easy to give permissions to just the instructor, TA, and individual student. The biggest problem I've encountered is that AFS requires a token that is not granted through the normal passwordless public/private key SSH login setup. Accessing a repository remotely therefore requires entering a password, sometimes per version control operation! This is a major pain for accessing the university-hosted server from anywhere else. If all development is happening on the university servers though, this problem does not come up.

CVS is an old version control system without many of the features you'd now expect. Checkins are not atomic and each file has its own independent version history. The only way to identify a single checkin is by date or to have the student tag it. File moves and deletions are not tracked or versioned well.

Common problems:

Notes and scripts on using CVS with AFS:

GIT on AFS

A clone of a GIT repository contains the entire history. This makes it possible to work and check in changes locally, then push them to the central repository all at once. GIT does not allow any access controls within a repository so it is necessary to create a separate repository for each student. This is a bigger pain for grading, but some shell scripting can make it a bit easier. The same problems with AFS and passwords over SSH make remote access to an AFS-hosted GIT repository a bit of a pain, but using it locally on the campus unix servers is still fine.

Common problems:

Notes and scripts on using GIT with AFS

GIT online

Services like github or bitbucket are widely used with lots of documentation. They can be easily accessed from anywhere. Scripting repository creation is a problem, though github's classroom lets you create a template repository that the students clone. This does make pushing updates a bit trickier though, since you have to explicitly pull them from the template and push back to the student's directory.

Common problems: