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.)
For real ease of use for your students, you could install a SVN server with autocommit turned on, shared using webdav. This way they can just mount their directory using WebDAV and will autcommit every time they hit save - accessing the history is easy with TortoiseSVN, the Eclipse / Visual Studio Plugins or some web access solution like ViewVC. For your access restriction needs you could use the integrated subversion authentication (look here) - which uses a simple configuration file for fine grained access control.
Configuration has become a lot easier (and there is better documention now - have a look at the SVN Book), but could get a bit coplicated if you need multiple separate repositories with access restrictions and a web interface.
Autocommit is more a solution for the "my office worker / boss" who has no clue whats going on inside a computer needs version control for word documents. Students taking a programming course should perhaps also learn how to use a decent SCM anyway.
Git and Mercurial would be nice because of their distributed nature, which makes sharing easy - but both tools lack GUI interfaces which are really easy to use (TortoiseHg looks promising, and gitk is a very good Repository browser, but your students would still have to wrap their heads around the command line tools to make full use of the tools). Also the concept of distributed SCM's is a little more complex to grasp.
On the pro side you could use public hosting solutions like GitHub and wouldn't have to worry about a server setup. This also makes sharing solutions really easy, but would break your "only with each other" requirement. But I guess you won't be able to stop them from exchanging code anyway, in my experience with course work I found looking at the code and verifying that it's unique is the only way to prevent copying.
You could also use PlasticSCM, which has really nice interfaces for a lot of IDE's and (at least the site claims) free licenses for educational institutions.
Second the choice of Mercurial
Advantages
Disadvantages
Subversion on Windows can be as simple as setting up TortoiseSVN. There is a bit of a learning curve for using it (especially if you've never used a version control before), but you might help that by dedicating half a lesson to it and providing some powerpoint slides for them to download.
As for centralization - I've heard of websites that offer free SVN project hosting. A quick Google search turned up this page, but there are certainly more.
Darcs is an excellent DVCS, especially for smaller projects such as ones for CS classes. I wish I was introduced to Darcs or Git in college, and I also commend you for introducing it to your students.
I use Git on a daily basis. It's a very robust DVCS, but maybe a bit of an overkill for smaller projects.
Take your pick, either of those version control systems are really good.
If you are looking for something that is really really esay to set up, then why not go for the free SVN hosting option, you don't have to set up a thing!
Sadly the two older ones that everyone would have pointed you to being Assembla, Unfuddle, have dropped support for their free hosting ( or at lest if you want them to private ), but you can still use Origo this give you both open and closed hosting.
The advantage of this is that you can own all the projects and follow them all, and easily control the people who have access, and you don't have to worry about right for creating repos.
If you do go this route, and you want to eliminate complexity then you must use a GUI svn application to make learning near trivial ( since I doubt there will be much merging going on ). I would recommend tortoisesvn, slips right into your windows explorer context menu.
I'd suggest looking at Fossil - It's a single executable with no dependencies to run, operates all traffic over HTTP, keeps its all repository data in a single file which can be named anything, and includes version controlled wiki, bug tracking and a web-server out of the box. Oh, and it's completely distributed.