Always Outnumbered, Always Outgunned
Or, in the case of software tools in education, always a step behind, but for a good reason. David Wolever recently wrote about how SVK has made his life better; he thinks it’s less painful to use than Subversion, and has hinted more than once that DrProject ought to switch. I’m willing to agree with the first, but not (yet) the second—not until there are tutorials that have had their tires kicked, a couple of books, plugins for Eclipse and other IDEs, desktop GUI integration, and everything else that comprises a mature, student-accessible software ecosystem.
I’m trying to teach good practices, which really means that I’m trying to persuade people to try something new based on my promise that it will make them more productive. SVK’s advantages aren’t apparent to beginners, who are really using version control for backup and as an alternative to emailing files to one another, so the “other stuff” that SVN offers makes it a winner. I feel the same way about SCons and Rake vs. Ant or Make, or JSON vs. XML: the newer tools would win if all other things were equal, but they’re not, so they don’t.
I sometimes hear people argue that if someone isn’t smart enough to figure it out on their own, they shouldn’t be programming anyway, but I don’t buy it. The productivity gains of newer tools are uncertain, but the costs of working with incomplete documentation and flaky integration are not, so the intelligent thing to do is actually to be conservative and let someone with a higher tolerance for pain (more charitably, someone who measures productivity in a different way) thrash their way through the undergrowth.
If and when the time comes to move to distributed version control, I don’t think SVK will win the ticket. You might want to look at Mercurial, which recently went 1.0 and has a hgbook. Additionally, it comes with a web interface built-in, is very light, and only requires Python to get going.
I really recommend it; the time has come.
This is slightly off-topic, but “using version control for backup” is one of the reasons I’ve switched to Bazaar from Subversion. With Subversion creating a new repository for a directory seemed really complicated. With Bazaar, it’s just “bzr init;bzr add .;bzr commit -m ‘initial version’”.
More on-topic, I think that this is one of the reasons backwards/cross-tool compatibility is so important. You don’t need to be running Bazaar or Svk for David and I to use them. They both (if I remember correctly) talk to Subversion repositories. So people who don’t learn the new tools can still get stuff done, but those of us who have more time to futz with partially-implemented things can still use the new tools and develop the tutorials/Eclipse plugins/etc.
“I don’t think SVK will win the ticket”
Nope — it sure won’t. Overall, it’s very mediocre. But when it comes to working with Subversion repositories, it’s the simplest one I’ve yet to see (although I’ve got my fingers crossed that bzr-svn will eventually be decent).
Yea, Blake, that’s exactly it — you and I can use bzr, svk, whatever, while everyone else uses Subversion.
I’ve been using bazaar for a 494 project this term. It’s a pleasure to use and very intuitive. But it’s definitely not ready for student use. There’s practically no IDE support (there’s bzr-eclipse, but it’s alpha and I’m afraid to use it), no visual tools to browse a repository/branch (like rapidsvn) or compile a checkin message from diffs (Subclipse rocks at this), and no web interface.
I find the documentation much better than for SVN, though. Reading the user guide for bzr taught me more than the entire SVN book.
DW: What don’t you like about bzr-svn? I’ve seen a lot of messages on the Bazaar mailing list from the author, and he seems more than happy to accept patches. Uh, I mean, more than happy to get feature requests, so that he knows what to work on next.
Dmitri: For visual tools, did you check out QBzr (http://bazaar-vcs.org/QBzr) or bzr-gtk (http://bazaar-vcs.org/bzr-gtk) or TortoiseBzr (http://bazaar-vcs.org/TortoiseBzr)?
For the checkin message from diffs, “bzr commit –show-diff” seems like it should do what you want.
For the web-interface, check out http://bzr.latte.ca/ (it’s running bzrweb, which you can find at https://launchpad.net/bzrweb/).
Blake: QBzr/bzr-gtk have this weird concept of just adding commands to start GUIs. I just know that for the first 2 months of using it, I’ll forget to prepend those q’s and g’s to the commands I use, and for the rest of the time, I’ll be typing svn gdiff and cursing when it doesn’t work. TortoiseBzr is windows-only. I already use –show-diff and it works for me, but Subclipse for example lets me choose which files to add/commit and I can double-click on any to view a diff.
Thanks for the bzrweb pointer. Didn’t know about this one.