Interview on Subversion
We made version control sexy again.
After big changes were announced for version control system Subversion, JAXenter spoke with C. Michael Pilato to find out more about what we can expect from future releases of Subversion.....
JAXenter: You recently laid down a proposed new roadmap and vision for Subversion, in which you state “Subversion has no future as a DVCS tool.” What led you to this conclusion?
C. Michael Pilato: The roadmap and vision I recently proposed for Subversion were actually the direct result of meetings by a small group of Subversion developers representing, among other things, different corporate sponsors of Subversion. CollabNet pays me (and others) to improve Subversion. There are other companies with Subversion developers on their payrolls, too. The best return on our corporate sponsors' collective investments into Subversion comes when we all work together, and with the rest of the Subversion development community, to move Subversion in the same direction. So, a couple of weeks ago, the aforementioned small group of Subversion developers got together in a conference room for a half-week to talk about how we could do exactly that. The result of those conversations was the roadmap and vision proposal, which I volunteered to author on behalf of the vision group.
Now, onto your question. If the noisiest of Netizens are to be believed, DVCS is the Only Way. Stroll into any public forum and whisper, "I'm thinking about switching to Subversion" and then just try to survive the virtual bludgeoning you'll receive at their hands because you aren't deploying git.
Distributed version control is a fascinating concept that has revolutionized the version control space. Subversion played a central role in breaking people free of chains they've long since assumed were just part and parcel of software development practices. We made version control sexy again. But DVCS has broken people free of chains they didn't even realize they had! So why not transform Subversion into Yet Another DVCS Offering? First, Subversion isn't architected for distribution, and it would really be a poor use of energy and time to try to rework Subversion into a truly distributed version control offering, when there are already several really good DVCS tools out there. But secondly, DVCS still doesn't cleanly solve some of the problems that Subversion's users want solved.
The vision group realized from anecdotal evidence and from targeted polling of our corporate user base that many users of Subversion would like to have some of the features that DVCS tools offer -- better handling of branches and merging, facilities for divorcing code checkpointing from code publishing/sharing, improved performance of the tool, and so on -- but they don't want to get those features at the cost of other things they feel they need. I'm sure there are those who would criticize us for not dispelling those sentiments and encouraging DVCS in the enterprise just like we encouraged and facilitated the CVS-to-Subversion transition years ago. But at the moment, at least, we find that these sentiments run pretty strongly behind the corporate firewall. When asked why they didn't just roll out a DVCS offering for their developers, many companies responded very resolutely, "No thanks. Our auditors would kill us." Subversion just needs to be the best Subversion it can be, continue serving the folks it serves, and grow to serve them even better. A day may come when centralized version control falls entirely out of favour with the world and DVCS (or some as-yet-undetermined newfangled thing) is naturally selected for survival, but that's no reason to pre-emptively curl up and die right now.
JAXenter: In your proposal, you envision Subversion version 2.0 with FS-NG enabled features. What do you think this could add to the Subversion experience?
C. Michael Pilato: I was one of the developers of Subversion's original repository storage backend, so I've been intimately involved in nearly every feature that has been introduced to Subversion which requires modifications to that layer of the software. Of course, today there are two backend options for that layer.
Unfortunately, the newer backend merely trades one set of problems for another. So now we have one backend that is a dream to develop for but has limited mindshare among users because of its strict deployment requirements, and another backend that is a dream to deploy but has limited innovative potential because of its strict development requirements. The end result is that very little progress gets made in this layer at all.
Given the opportunity to design a new FS-NG backend, the Subversion developers could address problems that we didn't realize ten years ago that we had, or that we'd have so much trouble implementing with the current design: better tracking of renames as first-class actions, bi-directional traversal of the history of versioned resources, archival/obliteration, access control lists, a new merge tracking design, etc.
JAXenter: In your proposal, you reveal that there have been no new full time committers to Subversion in the past year. Do you believe it's getting harder, to find people willing to commit to open source software?
C. Michael Pilato: Absolutely not. I believe open source software will only continue to grow in popularity and participation. When I was first introduced to open source software, the messaging was a weird mix of the hippy-happy "help make the world a better place" with the selfish "you can scratch your own itches.”
Neither of those messages is particularly motivational; at least not in a way that would cause folks to prioritize open source work highly. To the degree that more and more young developers realize the immediate benefits that open source development brings to them personally and professionally, we'll continue to see growth here. Were I in charge of a university computer science program, I'd be very tempted to make open source community participation a hard requirement for graduation -- not for the good of The World; not for the good of the projects; but for the good of the student.
Since you brought it up, I'll attribute Subversion's lack of new full time committers over the past year to three things. First, because Subversion is mature software, there is very little low-hanging fruit of the sort that tempts a new developer to enter a community and assert his or her ability to contribute meaningful changes to the code. Secondly, the Subversion developers were focused on everything except community development last year, ironically with the Apache Software Foundation transition eating up many of our mental cycles. We failed as a community to convert drive-by contributors into co-owners (in the sense of feeling personal pride in the software they've help create.)Finally, without a clear vision or roadmap for Subversion, its development practices have drifted from small groups of people working together on features, to individuals working largely in a vacuum, which isn't a particularly healthy or rewarding environment. Fortunately, we're in a great position to correct all of these things now.
JAXenter: How soon can we expect to see changes over at Subversion?
C.Michael Pilato: Well, Subversion itself changes daily -- just watch our commit mails fly by! I don't expect that the casual observer will notice the kinds of changes that we're talking about here, though. This is not exactly the stuff of press releases. I don't know. Maybe it will be press release fodder someday. Maybe a few years from now we'll read, "IBM to End-of-Life ClearCase -- Subversion Wins". That'd be kinda funky, wouldn't it?