In contrast to most software development organizations, our little research group within a university department consists of a professor and a flow of grad and undergrad students, it’s hard to retain any working knowledge beyond the research itself. Our backgrounds vary, and rarely involves much computer science background. (i have not myself ever taken a computer-related class.)
Yet we need to work on our homebrew software for planning and analysis, with distinction between the best current production version and development versions, protection against ill-conceived changes, ability to recall last year’s version, etc. It’ll be hard to get each student up to speed on subversion and learn to be careful about the repository, understanding branches/tags or however we organize it. (secondary question: how to get someone up to speed on svn?)
Perhaps one of the distributed version control systems would be better suited, or a centralized system other than svn would be wise, or if not, are there easily propagated practices with subversion we should follow?
I’d say that Subversion should give you the right balance between usefulness and easiness in an academic environment like the one you’re describing. I’ve been thinking about similar issues (I’m a physics graduate; I actually posted about something similar before), and my advice at the moment would be:
Set up a centralized version control system, preferably SVN. With grads and undergrads appearing and disappearing all the time, I’d say that distributed version control might well lead to revisions that people are working on ‘locally’ disappearing with them. Centralized version control would give you ‘One True Revision’.
Let everyone experiment with a small test repository, so they can get the hang of it. If you search around SO, you will find plenty of questions & answers referring to good tutorials.
Perhaps consider renting a hosted SVN repository, it might save you the hassle of setting up your own on your local network. (Some universities I know have very strict rules for network security, so getting your own server is sometimes a long and complicated bureaucratic process.)
Tell your students: code does not exist until it’s checked in! And I guess they will soon enough discover the advantages of VC, once they have to do their first ‘revert’/’rollback’ 🙂
As for getting students up to speed with Svn: see the Software Carpentry Course on Version Control and the ‘Getting started’ chapter in the Subversion book. You may also want to have a more experienced person just sit with a new student once or twice (seems like a waste of time, but pays back double!).
Note, though, that I don’t have much actual experience with this. So I would be very happy if you could, e.g., post back some time later to tell us about your experiences!