4

For CS undergraduate students working on a 2-semester capstone course without any prior exposure to revision control systems, what would be a good one to use?

Desirable qualities would be easy to use (ie this should be a tool they can use rather than spend a lot of time fighting it) and still be relevant for subsequent professional work once they graduate (doesn't have to mean it has to be the same tool later on as long as the concepts survive).

Easy to install and maintain for the person who does this. Not sure if I am missing anything else important.

I am aware of subversion (centralized), git (distributed) and mercurial(also distributed?) - but don't know enough about any of them to have an informed opinion. Are there others I should consider? This will be on a predominantly Windows environment.

EDIT: I am really interested in the pedagocial aspect of teaching/learning these systems, not so much from the perspective of an already experienced software developer.

gnat
  • 20,543
  • 29
  • 115
  • 306
Levon
  • 278

3 Answers3

12
  • Git: most powerful, steepest learning curve. Support under Windows was not stellar last time I checked. Unless the students are already familiar with it, think twice. Extremely popular so it might be worth teaching nevertheless.
  • Mercurial: easier than git, but still distributed with all the advantages of this (cheap branching, work offline). Should take less effort teaching. Supported well under Windows.
  • Subversion: centralized, conceptually the simplest of the three, but not significantly. Supported well under Windows. Needs the students to be always connected to the server to reap the benefits of version control. Used to be least friendly of all when merging.

I'd take Mercurial.

9000
  • 24,342
5

I wish git or mercurial were around when I was in college. I think we used cvs for our big group project, and it was difficult getting the entire team to use it. Part of the problem is college students often have a laptop as their only computer, with spotty internet service that often firewalls any non-http traffic. Either that, or they use school computer labs with the same firewall issues, and that rarely have a source control client installed. Even if you personally are better equipped than that, you have to think about the lowest common denominator on your team.

With distributed version control, you can put the client and a repo on a laptop or usb drive and work completely disconnected most of the time, with lots of different ways to share your changes: sites like github, emailing bundles back and forth, or even just pushing and pulling from each other's thumb drives or laptops on a LAN when you get together for team meetings.

I might throw bzr into the ring. It's more noob friendly than either mercurial or git, but also not as flexible. Git has a reputation of being difficult for noobs. The bare essentials are as easy to learn as any other VCS, but people get overwhelmed by all the different advanced options available, and aren't sure what's safe to ignore or not. Its CLI syntax is also very unix-like, which makes it feel very intuitive for *nix users but a little quirky to others. Mercurial's a good balance. It hides a lot of the complexity, but is still very capable, with a syntax more familiar to Windows users.

Karl Bielefeldt
  • 148,830
3

Git is probably the best one.

There is the Git-Client SmartGit (and similar ones) for newcomers. Git is very popular and there is github, where students can store the files. (At my university all courses use git. In most cases the repositories are public hosted on github.)

mrsteve
  • 450