We made version control sexy again.
JAXenter speaks with C. Michael Pilato on his recently-released roadmap and vision for Subversion.
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
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.
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
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
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
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