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

Setting up a subversion repository is trivial; I frequently set one up as a one-off thing for small projects (such as developing code for an answer on Stack Overflow!), and I doubt anybody else who could learn an SCM system at all would have any trouble with it.

$ svnadmin create /home/cjs/repo
$ mkdir my-project
$ cd my-project
$ vi hello.c
  [...hack hack hack...]
$ svn import -m 'Initial project import.' file:///home/cjs/repo
Adding         hello.c

Committed revision 1.

That said, sharing is certainly an issue. If the students always work together when they work simultaneously, they could use a USB drive, since they can just unplug it and pass it back and forth when one needs to comit, and the person who's going to program alone later can just hang on to it. That's not entirely convenient, though.

Another option, since they all appear to be working on a shared Unix system, is to create a directory with the execute but not read bit set for the rest of the group (or all users) and use a s3cr3t name for the repo under that, one that only the two students know. Passing that secret name on to the prof would allow him to examine student's repos at any time, as well. ("So you submitted the assignment on time, but the e-mail system lost it? Let me just look at the time of that commit....") A script could help set this up.

In fact, the more I think about that, the more I'm beginning to like it. In certain ways, it's simpler than the git solution because the student doesn't have to deal with passing patches around (or forgetting to do so) and the student will be forced to deal with merges before he commits, rather than once things are in the repository (with the subsequent ability to delay dealing with that indefinitely).

Answer 2

RCS for linux.

I've found nothing simpler than RCS for Widows but not all the RCS ports work well so you have to try them which makes it non-simple. Windows just isn't simple for developers. The windows port from http://www.cs.purdue.edu/homes/trinkle/RCS/ is pretty good.

Answer 3

Subversion is easy to install, on windows, linux and mac os x. I don't know what program they are programming in, but the subclipse plugin for Eclipse is fairly easy to install and hides away some of the repository complexity.

And repository complexity? That's simply having a trunk, tags and branches folder within each project anyway. And they might not have much time, but they should get the time to learn SVN (or similar) because it is a skill that looks good on their CV.

Answer 4

I would say your best bet will be to try to work with your IT department to set up a system/method for your students to easily create new SVN/CVS repositories.

Probably you could get the IT department to give you the privileges necessary to create repositories for your students even if they won't give the priveleges to the students themselves. You could probably pretty easily write a few scripts to mass-create repositories from lists of students at the beginning of the semester.

Answer 5

I have had some very good experience with Bazaar. Like Git/Mercurial it is distributed. It is serverless - you do not need a daemon installed on the server hosting the repository, even if you are accessing it remotely (ie, it can work just as an FTP/SFTP share).

A distributed VCS is most flexible. You can check out a branch from a more traditional 'central' repository and gain all the benefit of being able to fork off your own little development separate to the central server, etc and then, perhaps, push your changes back up.

There are import tools for other VCSs such as Subversion though I haven't tried them.

Answer 6

I would recommend Mercurial (also called 'hg'). It is a distributed open-source VCS, and needs no central repository. Using it day-to day is easy. There is enough documentation on official site. For example check out QuickStart.

Deciding point for me was a great GUI for Windows - TortoiseHg. It seems it is also supported on Linux (didn't try myself). And of course there are command-line distributions for most Linux versions.

Of course it seems easy from this side of the fence, maybe for busy students concept, advantages, and everyday operation won't be that easy to get used to. But in the end, instant commits, ability to revert to any revision and create a new branch from there automatically, and intelligent diff/merge are just irreplaceable.

Hope this helps!