What version-control system is most trivial to set

Question

I teach the third required intro course in a CS department. One of my homework assignments asks students to speed up code they have written for a previous assignment. Factor-of-ten speedups are routine; factors of 100 or 1000 are not unheard of. (For a factor of 1000 speedup you have to have made rookie mistakes with malloc().)

Programs are improved by a sequence is small changes. I ask students to record and describe each change and the resulting improvement.

While you're improving a program it is also possible to break it. Wouldn't it be nice to back out?

You can see where I'm going with this: my students would benefit enormously from version control. But there are some caveats:

• Our computing environment is locked down. Anything that depends on a central repository is suspect.
• Our students are incredibly overloaded. Not just classes but jobs, sports, music, you name it. For them to use a new tool it has to be incredibly easy and have obvious benefits.
• Our students do most work in pairs. Getting bits back and forth between accounts is problematic. Could this problem also be solved by distributed version control?
• Complexity is the enemy. I know setting up a CVS repository is too baffling---I myself still have trouble because I only do it once a year. I'm told SVN is even harder.

Here are my comments on existing systems:

• I think central version control (CVS or SVN) is ruled out because our students don't have the administrative privileges needed to make a repository that they can share with one other student. (We are stuck with Unix file permissions.) Also, setup on CVS or SVN is too hard.
• darcs is way easy to set up, but it's not obvious how you share things. darcs send (to send patches by email) seems promising but it's not clear how to set it up.
• The introductory documentation for git is not for beginners. Like CVS setup, it's something I myself have trouble with.

I'm soliciting suggestions for what source-control to use with beginning students. I suspect we can find resources to put a thin veneer over an existing system and to simplify existing documentation. We probably don't have resources to write new documentation.

So, what's really easy to setup, commit, revert, and share changes with a partner but does not have to be easy to merge or to work at scale?

A key constraint is that programming pairs have to be able to share work with each other and only each other, and pairs change every week. Our infrastructure is Linux, Solaris, and Windows with a netapp filer. I doubt my IT staff wants to create a Unix group for each pair of students. Is there an easier solution I've overlooked?

(Thanks for the accepted answer, which beats the others on account of its excellent reference to Git Magic as well as the helpful comments.)

Answer 1

I see no reason for dealing with setting up the source control system. Review the terms for using e.g. google code and dive in.

A fellow CS student and I used it last year and it works great and the only precondition is an internet connection :-)

Answer 2

darcs send is trivial to setup - when you run darcs send <remote repo>, it looks in _darcs/prefs/email of the remote repo to decide where to sent the email to. If there's nothing there then it prompts the user instead.

The receiver of the patch just saves the file and runs darcs apply <patch file> in the appropriate repo.

So each student can just have their own repos with their own email address in _darcs/prefs/email and exchange patches by email.

Answer 3

I would say something like Git might fit the bill:

• As it's a distributed system, you don't need to have a central repository, the repos exist with the source directory
• It is easy to create patch files that can be mailed and applied.
• Although it might seem that git is difficult to use, the basic ideas of committing, merging, adding and removing files are not that hard to learn.

Have a look at this site Git Magic or, even this tip site GitReady

Answer 4

Regarding permissions, an outside service wouldn't require time from your university's IT staff.

For example, Bitbucket (using Mercurial) now allows unlimited private repos with up to 5 users. I'm guessing each new weekly pair of students is working on a new project together, which means they can just initialize the repository, add the other user, and away they go.

If they are not working on a new project every week, permissions would have to be removed and added, and I'd encourage them to have multiple repos (one per account) on Bitbucket so each student has continued access. (This would be a good idea anyway, but for only week-long projects, it may be simpler to just have one student account own the repo and the other with permission.)

Regarding which VCS, I believe Mercurial will be best given your platforms—TortoiseHg being particularly good for new users to explore, if they're unfamiliar with (and you don't have time for them to learn) command-line interfaces.

Specific to your situation, the advantage of DVCS is their copy on the university server (if there is one) is a fully-fledged repo. You may find it convenient for you or TAs to have access, which should be simpler to setup and would last all semester instead of change weekly.

Answer 5

UPDATE: Six years later I would never consider using subversion for anything ever again. Git is the way to go. So, while I still think SVN is a bit "simpler", it is just not even worth teaching anymore.

I've used CVS, SVN, Bazaar and Git (in that order of introduction) and I'd have to say for students that SVN is the way to go. In fact, while I was lead TA we implemented SVN as a replacement for the old "submit script" which was a tar and email script. Labstaff setup an Apache SVN-DAV based repository and using the authz file the TAs and instructor could control permissions for per-student directories and group projects at a very fine-grained level leaving students with a very simple path to their first commit. See my tutorial (credentials ripped out by the most recent TAs.. hmm..)

Regarding the use of subversion without intervention by sys admins, I've done this as well in a group-project setting where none of my group members had ever used subversion before and most of them were committing with very little confusion (all but one). I also wrote a tutorial for setting up such a secure shared repository with only basic SSH access here.

I definitely disagree that git is the best VCS for beginners having experienced the blank looks enough at the mention of any VCS system, let alone the mac-daddy-written-by-Linus-himself VCS king, git. It is simply not true that git is no more complex than svn, and the lack of mature n00b tools alone is enough of a reason not to use it in this scenario. I just started using git for a new project that I am developing in Netbeans and already ran into serious limitations with the Netbeans integration. In a single semester you are not going to use any functionality that svn doesn't provide so git is overkill.

Answer 6

Bazaar, Mercurial, and Git sound appropriate for your case - trivial to create repositories, and all the students need to share is read access on the filesystem to each other's repositories.