Subversion’s Future?

This entry was posted by on Tuesday, 29 April, 2008 at

According to Google Analytics, one of the most heavily trafficked posts on my blog is the one I wrote years ago, the Risks of Distributed Version Control. It’s full of a lot of semi-angry comments about how wrong I am. I thought I would follow up to that post with some newer thoughts and news.

I have to say, after using Mercurial for a bit, I think distributed version control is pretty neat stuff. As Subversion tests a final release candidate for 1.5 (which features limited merge-tracking abilities), there’s a bit of angst going on in the Subversion developer community about what exactly the future of Subversion is. Mercurial and Git are everywhere, getting more popular all the time (certainly among the 20% trailblazers). What role does Subversion — a “best of breed” centralized version control system — have in a world where everyone is slowly moving to decentralized systems? Subversion has clearly accomplished the mission we established back in 2000 (“to replace CVS”). But you can’t hold still. If Subversion doesn’t have a clear mission going into the future, it will be replaced by something shinier. It might be Mercurial or Git, or maybe something else. Ideally, Subversion would replace itself. :-) If we were to design Subversion 2.0, how would we do it?

Last week one of our developers wrote an elegant email that summarizes a potential new mission statement very well. You should really read the whole thing here. Here’s a nice excerpt:

I'm pretty confident that, for a new open source project of non-huge
size, I would not choose Subversion to host it [...]

So does that mean Subversion is dead? That we should all jump ship
and just write a new front-end for git and make sure it runs on
windows?

Nah. Centralized version control is still good for some things:

* Working on huge projects where putting all of the *current* source
  code on everyone's machine is infeasible, let alone complete
  history (but where atomic commits across arbitrary pieces of the
  project are required).
* Read authorization! A client/server model is pretty key if you
  just plain aren't allowed to give everyone all the data. (Sure,
  there are theoretical ways to do read authorization in distributed
  systems, but they aren't that easy.)

My opinion? The Subversion project shouldn't spend any more time
trying to make Subversion a better version control tool for non-huge
open source projects. Subversion is already decent for that task, and
other tools have greater potential than it. We need to focus on
making Subversion the best tool for organizations whose users need to
interact with repositories in complex ways[...]

I’ve chatted with other developers, and we’ve all come to some similar private conclusions about Subversion’s future. First, we think that this will probably be the “final” centralized system that gets written in the open source world — it represents the end-of-the-line for this model of code collaboration. It will continue to be used for many years, but specifically it will gain huge mindshare in the corporate world, while (eventually) losing mindshare to distributed systems in the open-source arena. Those of us living in the open source universe really have a skewed view of reality. From where we stand, it may seem like “everyone’s switching to git”, but then when you look at a graph like the one below (which shows all public (not private!) Apache Subversion servers discoverable on the internet), you can see that Subversion isn’t anywhere near “fading away”. Quite the opposite: its adoption is still growing quadratically in the corporate world, with no sign of slowing down. This is happening independently of open source trailblazers losing interest in it. It may end up becoming a mainly “corporate” open source project (that is, all development funded by corporations that depend on it), but that’s a fine way for a piece of mature software to settle down. :-)

71 Comments to Subversion’s Future?

  1. Augie Fackler says:

    April 29th, 2008 at 10:46 pm

    I’ve noticed the same kind of trend, and I think that we’re moving (at least for corporate uses) towards a hybrid model, where a system like Subversion is the core, and the 20% use some DVCS to interop with the centralized system with extra power.

    I’m glad to see I’m not alone in thinking that the corporate world (especially someplace like Google or Apple with loads of IP to protect) will stay on a fundamentally central model. I think that Mercurial and Git will eventually both become sort of super-clients, that can be used as either a DVCS or as an interface to Subversion (or CVS/whatever) itself.

    The one fear I have of this is that right now at work I do my work in feature branches, which means that people can see and comment on my progress if desired, and even if I’m hit by a bus my work can still be finished in a hurry. With a DVCS tool working as a super-client, you (probably) end up losing this layer of security. Got any thoughts on that potential loss?

  2. Karl Fogel says:

    April 30th, 2008 at 9:57 am

    Well said. And note that the centralized version-control space is a big place, and not all of it has been explored — that is, Subversion is still growing new features, and will continue to do so. “Maturity” does not necessarily mean “settling down”. The part you quote from David Glasser is important: “We need to focus on
    making Subversion the best tool for organizations whose users need to
    interact with repositories in complex ways…” For example, sparse checkouts, complex authorization needs, preservation of auditable review trails, etc.

    These things are probably most useful to the corporate world, and to governmental and military organizations. Subversion has an interesting future… :-)

  3. John Wiegley says:

    April 30th, 2008 at 1:02 pm

    @Augie With DVCS you can still opt to push your local development branches over to the “main” repository. The only commits that are local-only will be those that happen before you’re able to reach Internet and push upward. This is wholly a choice of the user, and is not mandated by the DVCS paradigm. I tend to push branches people may be interested in tracking, and rely on regular backups for those that are truly experimental.

    @author It’s possible with Git to create a “shallow clone”, although it isn’t a standard practice (see http://www.gelato.unsw.edu.au/archives/git/0511/11390.html). This is an area where Git could be improved by those with experience in the needs of centralized users.

  4. Christian Knott says:

    April 30th, 2008 at 1:41 pm

    While I’m personally fascinated by the rise of Distributed VCS (DVCS) in the open source world and, separately, the amount of buzz it is getting I think it is far from a done deal.

    VCS is a broad field: disparate examples include the needs of vast organizations, the most distributed of development teams and small shops/groups. At the moment DVCS seems to fit large scale distributed development teams well, but fit other models relatively poorly.

    It will be interesting to see whether DVCS can “cross the chasm” from the early adopters to broad acceptance. Even if it does, Subversion and other commercial VCS systems still have a place. The balance may change, but the need for mature, robust and scaleable free centralized VCS (i.e. Subversion) will continue for a long, long time.

    ———————-
    Christian Knott
    alphasoftware.com

  5. bartman says:

    April 30th, 2008 at 2:03 pm

    So I don’t think I agree with the reasons why centralized approach is reasonable; I am a git user, but I am sure that there are non-git DVCS’es which allow for the same functionality. If they don’t… why do they still exist? :)

    * putting all of the *current* source code on everyone’s machine is infeasible

    Git shallow clones permit me to clone an incomplete tree. If I am not interested in all the history.

    Git modules allow the maintainers to split their work into functional units. Users can then clone the appropriate unit they need. I agree that this requires some planning… unlike with CVS and SVN which allows you to do this on the fly.

    * Read authorization!

    There is no such thing with SVN today. If I have SVN access to the gree, I can with only one command make a git repository with all the history which I can then share with the world.

  6. Brian Hogan says:

    April 30th, 2008 at 2:07 pm

    I’m not at all ready to give up Subversion as my base repository for my projects and for projects for clients. However, I love the speed of Git and I love how trivial branching works. I love how the history is local. I want the best of both worlds… and so I use git-svn to bridge. It would be interesting to see better cross-system tools, as I have noticed quirks with this approach. Allowing SVN to be the “official” repository while letting developers use git is an interesting model.

  7. Florian says:

    April 30th, 2008 at 3:14 pm

    I disagree with the sentiment that an open collaboration structure encourages anti-social behavior.

    To the defense I want to point out everybody’s poster child of dvcs usage, linux, which wouldn’t be possible with a centralized, everything life, environment (partly out of sheer size, partly because there’s many gatekeepers).

    Also keep in mind that to deal with the bomb phenomenon git and mercurial can accept patchsets (and stack them), such that you can try on a bomb. If it explodes in your face you can scald the submitter of the patch and drop the patchset again, and if it works out fine you can merge it into your repository.

    Finally do also keep in mind that code-review, especially of big projects can’t be done by one person alone, and if you intend to organize the workflow of this in any way, you end up with a tree structure where patches flow upstream by review and merge, and eventually they arrive at the reference repository, from where they propagate downstream to everybody else again. DVCS is what allows this.

  8. Sam Hart says:

    April 30th, 2008 at 3:27 pm

    Meh, honestly, the two bullet points quoted in the post aren’t that valid.

    “Working on huge projects…”

    This isn’t that valid since hard drive space is cheap. There’s plenty of projects I’d say are *extremely* large that are hosted in DVCSes (Solaris comes to mind). In this regard, the gains you get in SVN are extraordinarily minor to the point of barely even being a blip…

    “Read authorization!”

    This was the one reason I stuck with SVN as long as I did… but once Hg came out with the easy to set up hgweb script this is no longer an issue. I virtually have *every* read/write authorization capability that I had with SVN, except now I also have distributed version control to boot. Anyone who seriously attempts to argue this point simply hasn’t looked at what Hg offers in this regard (though the point is still valid with every other DVCS out there: git, bzr, darcs, they all fail this).

    Now, you may argue that having the repo on a local filesystem that is no longer protected by an authenticated server/client scheme nullifies this and makes it a problem again (after all, people can just “hg clone” the local filesystem repository), but it doesn’t make any problems that weren’t already present in SVN (a local SVN checkout can still be copied and moved around just as easily, SVN doesn’t protect any data other than history.)

    So anyway, both of these points really aren’t valid generally. And, specifically with regard to Hg, the points aren’t true.

  9. huperniketes says:

    April 30th, 2008 at 3:46 pm

    While it may be fine for hobbyists and early-adopters to experiment with new technologies like GUIs and user-friendly fads, corporate users and real-world practices still depend on DOS for day-to-day operations and will continue to do so for the foreseeable future. Lotus 1-2-3 dominates the market so convincingly, they’ll have no difficulty translating that lead to whatever new platforms their customers adopt in the future. — The enterprise customer of 1990

    At least I already know the project team has chosen to hold to project management practices which are out of step with a global, and increasingly mobile, workforce. So if Subversion has successfully replaced CVS, then it is the new CVS. Goodbye, CVS!

  10. Stephen Smoogen says:

    April 30th, 2008 at 4:13 pm

    I was thinking that read authorization was so that group A, B, and C could all see different parts of the project while say group D can only read parts of B & C. This comes up in the corporate world where various political and financial matters dictate who can see what or write to what.

    Does write authorization come into play here also?

  11. doce cosas : El futuro de SVN says:

    April 30th, 2008 at 4:23 pm

    [...] Acabo de leer “Subversion’s Future?” en el uno de los diseñadores y desarrolladores de SVN habla sobre el futuro de SVN después del gran boom de los sistemas distribuidos de control de versiones. En el artículo se habla del futuro de SVN una vez que han conseguido el objetivo y sabiendo que necesitan otro. What role does Subversion — a “best of breed” centralized version control system — have in a world where everyone is slowly moving to decentralized systems? Subversion has clearly accomplished the mission we established back in 2000 (“to replace CVS”). But you can’t hold still. If Subversion doesn’t have a clear mission going into the future, it will be replaced by something shinier. It might be Mercurial or Git, or maybe something else. Ideally, Subversion would replace itself. :-) If we were to design Subversion 2.0, how would we do it? [...]

  12. linuxrocks123 says:

    April 30th, 2008 at 4:40 pm

    Here’s the way I (ab)use Subversion: I store my entire home directory in it. Yup, I have an approximately 25GB Subversion repository containing all my music, personal programming projects, OpenOffice.org and LaTeX documents, the whole works. It’s hosted on an old Ultra 10, and I have this respository checked out on each of my machines.

    What amazes me is this actually works. I ran into a 2GB file size limit problem with the fsfs backend, but, once I switched to Berkeley, I was able to “svn import” my entire home directory fine, and commits are reasonably fast.

    I recognize that this is probably an abuse of the tool, but Subversion has provided me a convenient way to get file system synchronization, history, and incredibly good undelete protection for not much cost. As an added bonus, it also provides source code version control for my programming projects as a standard part of the system. I can’t even imagine doing something like this with git — it would probably just crash. Subversion is an irreplaceable asset to the OSS community.

  13. Karl Fogel says:

    April 30th, 2008 at 5:07 pm

    Hard drive space isn’t cheap when the master project is hundreds of gigs large. Open source projects in general tend not to be large (the flattering explanation is that maybe such projects are better at code re-use), and can almost always be checked out in their entirety. But many corporate projects are simply too big to check out — not only in terms of disk space, but in terms of time: you need to be able to select subsets in order to have manageable checkout and update times, if the amount of date and/or churn rate is too high.

  14. Subversion considers its future | Open Source Pixels says:

    April 30th, 2008 at 5:11 pm

    [...] Ben Collins-Sussman has posted an interesting note on the future of Subversion and centralized version control. “I’ve chatted with other developers, and we’ve all come to some similar private conclusions about Subversion’s future. First, we think that this will probably be the ‘final’ centralized system that gets written in the open source world – it represents the end-of-the-line for this model of code collaboration. It will continue to be used for many years, but specifically it will gain huge mindshare in the corporate world, while (eventually) losing mindshare to distributed systems in the open-source arena.” [...]

  15. Jeff Leyser says:

    April 30th, 2008 at 5:17 pm

    If you “need to focus on making Subversion the best tool for organizations whose users need to interact with repositories in complex ways” then doesn’t the new mission statement become “to replace ClearCase?”

    I can think of worse goals for a VCS.

  16. Matthew says:

    April 30th, 2008 at 5:28 pm

    I’m still sold on Perforce. Centralized, but merging/integrating/etc feels a whole lot more natural and so I have a hard time following the centralized/decentralized debate. It feels more like I’d want to use git in any case over subversion (especially for open source), but Perforce everywhere else (especially in a company).

    Any long-time Perforce and git users to comment?

  17. James Roper says:

    April 30th, 2008 at 6:22 pm

    I agree strongly with what you said about people in the open source universe having a skewed view. I used to work for a giant corporate IT services provider, and I would very highly doubt that the corporate world will ever start using distributed version control systems en masse. We had teams of 10 or so people, that support 100s of software applications, ranging in size from 5KLOC to 500KLOC. In this context, it just wouldn’t make sense to use a DVCS. People may not touch the code of a particular application for a year, they would only check it out from the repository whenever they need to make changes, and after they would often delete it to reclaim hard disk space on their machines. That environment is much better suited to a centralised version control system. And, most applications that I’ve seen are still on CVS, when I left we were only just starting to use SVN for some in house experimental projects. Though, SVN was on the cards to replace CVS in the near future. If anything ever replaces SVN in the corporate world, it won’t be a DVCS.

  18. Chris Heller says:

    April 30th, 2008 at 6:38 pm

    The other thing to keep in mind about “enterprise version control” is that there is still a huge amount of work that happens in an enterprise that should be under version control, but it is not. You’d think that wouldn’t true by now, but you’d be surprised.

    Part of that is related to the fact that it’s easier than ever for people who don’t have the word “developer” in their job title or as their primary job function to be creating / maintaining IT related work. And it’s not just people writing macros in spreadsheets either.

    Getting those folks to use version control, centralized or not, is still a huge challenge. Making it easier for the non-”developer” to gain the benefits of version control is key. The (relative) ease of use of Subversion is certainly part of the reason for it’s ongoing success in the enterprise.

  19. n[ate]vw says:

    April 30th, 2008 at 7:01 pm

    I am an independent developer who has been working solo for about 5 months, and gradually hope to add other developers to the team. We will be working in an essentially centralized fashion, but we will not be using Subversion. I am fully on board the DVCS train, enjoying Bazaar until they stop competing with Mercurial. I don’t know if I’ll ever use “svnadmin” again.

    I am grateful for this candid post. I had sort of left feeling bitter that the Subversion team did not understand my needs as a user. Fixing the bundled documents issue with the .svn litter might have kept me on board a little while longer, and maybe I would have figured out how to use SVK on my laptop. In the end though, I am just not in your target market, nor are a lot of other developers. I am glad the Subversion team understands this.

    You have a great centralized system, provided some of the long-standing annoyances can be resolved. Many developers will have an SCM system forced upon them by someone who doesn’t have to use it much themselves. It’s great to know that you will working to make Subversion be that system.

    I guess this is farewell, but with all the good wishes that implies. Thanks to anyone who has or will contribute to this project. You had earned your popularity in the open source world, and I have no doubts you will earn your consulting fees in a more lucrative market!

  20. Daniel Berlin says:

    April 30th, 2008 at 7:06 pm

    DCVS won’t take over the world as long as it’s users keep claiming there is absolutely nothing wrong with it and everything is perfect.
    Examples:
    “hard drives are cheap” – Great talking point, completely useless in the real world, where buying bigger hard drives for 10,000 developers (or really large NFS servers) is not feasible.
    “Subversion’s read authorization doesn’t prevent you from copying checkouts anyway” – This is only mildly relevant (It has nothing to do with read authorization, and everything to do with local security), and where most DCVS have *no fine grain control at all*, not an acceptable answer. Just because something doesn’t do an amazing job at something doesn’t mean you can do nothing and still claim to be doing okay.

    Lastly, if DCVS’s like git want to actually take over the world, they need to stop telling everyone else they are broken, and try to change everyone else’s workflow, and learn to work with their potential users. Telling users “hey, just change the way you do everything” just doesn’t cut it, even if your way really is better (which is often debatable). You don’t get anywhere by trying to change everyone else, but instead, by learning to work with everyone else. You certainly can’t be everyone’s perfect tool, but most DCVSen (hg is pretty different here since they make a concerted effort to find out what their potential users want) are too far on the extreme side of “no, change the way you work” when it comes to UI.

  21. David Glasser says:

    April 30th, 2008 at 8:07 pm

    (I’m the author of the quoted message, for what it’s worth.)

    For those claiming that “putting all of the *current* source code on everyone’s machine is infeasible” is not a real use case, just trust me that to me, this is not a theoretical statement. As Karl says, many corporate projects just can’t be checked out at once. Organizing code into multiple repositories (“hg forest” / “git modules” / etc) is a partial solution, but suddenly you lose the ability to atomically commit and branch across your whole codebase, which is a serious requirement for many organizations. (These solutions are similar to svn’s externals, which like them end up being flawed in practice.)

    With respect to read authorization:

    bartman, yes, of course given read access to the tree, a human can send restricted data to those who shouldn’t see it. But there’s no practical technical solution to this social problem. There’s also nothing technically stopping the folks with the USA’s nuclear access codes from calling me and telling them to me; however, there’s a lot more stopping me from finding them out without a cooperating insider. Similarly, Subversion’s read-based access control prevents an attacker from reading secret parts of the repository, though it certainly doesn’t stop an insider from leaking.
    Sam Hart: Can you show me a pointer to hg’s support for read authorization at the sub-repository level? Last time I checked, there was no such thing. (This is pretty different from the ability to control access to an entire repository, of course.) If there is, I’d be incredibly curious to find out how they do it! (The only ways I know of to implement read access control in a git model or mercurial model involve a lot of crypto overhead, with all the usual fun PKI problems.)

  22. Fats says:

    April 30th, 2008 at 8:40 pm

    Actually there already exists an distributed version of subversion. SVK …
    I am already using subversion in a distributed way with this program.

  23. Nath says:

    April 30th, 2008 at 9:51 pm

    Don’t know of ANYONE in the commercial world using distributed source control.
    You’re correct: that small sector of open source is most definitely out of the loop. Must be the same bunch claiming ruby is the only language anyone uses :)

    Seriously: there are a bunch of people who flit from one “cool” thing to the next with no real idea of how the rest of the world works. Writing bits of unused throwaway code in unused throwaway fad languages while the rest of the world uses java or c# to get things done that service userbases ranging from hundreds to tens of thousands of users doing REAL work.

    Subversion is very much used and on the up (as the graph shows). If anyone’s considering ditching subversion development or doesn’t see the future in it: let me be the first to give you a good slap in the back of the head.

  24. Ted Naleid » Using Mercurial as a “super client” for Subversion says:

    April 30th, 2008 at 10:07 pm

    [...] There’s a post on the official subversion blog talking about the future of subversion in a DVCS world. [...]

  25. Ben Collins-Sussman says:

    April 30th, 2008 at 10:25 pm

    FYI: Subversion, as a project, is still listening to users. As DannyB said, we’re not in the business of telling users to change the way they work; in general we take feedback and try to give users what they ask for.

    The last year has been harrowing for the svn developer community, because (surprise surprise), implementing merge-tracking is a Really Hard problem. It was the one big thing left that commercial centralized systems could do (Perforce, Clearcase, etc.) but Subversion couldn’t. Subversion 1.5 (now in release candidate) should ease most of the pain here: users will now be able to repeatedly run ‘svn merge’ (with no revision arguments) and the system will usually do the right thing, just like ‘p4 integrate’ does.

    The next Big Thing on the plate is a major rewrite of the working copy: centralized metadata (no .svn/ turds littered around!), fast scanning, the optional ability to keep things read-only (and an ‘svn edit’ command to make them read-write), and a general goal of making the working copy less ‘fragile’ in terms of locking up or getting into bad states. This is a serious usability hurdle, but will be well worth the effort.

    And of course, some of us are still flirting with the idea of borrowing DVCS features as well. What if a working copy could store some or all of the repository history, to allow offline commits? What if svn repositories really could be taught to swap changes with each other? Lots of blue-sky ideas out there.

  26. RAF says:

    April 30th, 2008 at 10:26 pm

    One thing that is overlooked here is that many corporate development teams are still using CVS, and still talking about migrating to SVN.
    Not to mention the idiots who are still using M$ source-unsafe, and thinking about moving to CVS or SVN (or not).

  27. Sean’s Mental Walkabout » Blog Archive » links for 2008-05-01 says:

    April 30th, 2008 at 11:33 pm

    [...] iBanjo » Blog Archive » Subversion’s Future? Interesting post on the place for subversion in the future (tags: future opensource programming software svn versioncontrol) [...]

  28. Sam Vilain says:

    April 30th, 2008 at 11:47 pm

    You make the disk space for distributed VCS argument, yet don’t acknowledge that for many projects, a complete git clone is still less disk space than a simple SVN head checkout.

    Others have pointed out that git can shallow clone, chipping away further from the disk space argument. “sparse checkout” is an upcoming feature that will let you check out only part of a tree. It’s taken a while to arrive, mostly because most people just don’t need it.

    David Glasser, check your information – git’s submodules are inherently atomic. Probably hg’s forest, too. Just because svn:externals are flawed, does not mean that the others are flawed, too.

  29. Sean says:

    May 1st, 2008 at 1:10 am

    We use Mercurial for about 20 projects involving about 50 developers. We originally used Subversion but needed to work remotely with other company sites. We also do kernel development and wanted something ‘like-git’ but easier to use.

    The problem is that as the number of developers grows and the complexity of the access requirements increases, I look longingly at enterprise vcs solutions rather than this crude sort of shell based script hacking that has to go on behind the scenes to keep everything afloat.

    Sean

  30. Tim Dysinger says:

    May 1st, 2008 at 1:49 am

    One thing that is overlooked here is that svn and cvs sucks – even on large projects. Centralized source control is dead.

  31. Berend Botje says:

    May 1st, 2008 at 2:05 am

    As a corporate SVN user, I’m not worried about SVN losing mindshare to DVCS, I’m worried about SVN losing mindshare to Microsoft Team Foundation Server.

  32. Ben Collins-Sussman says:

    May 1st, 2008 at 7:02 am

    @Tim Dysinger: thanks for that deep, insightful comment. :-)

  33. Ashwani Kaul says:

    May 1st, 2008 at 7:21 am

    Very well said. Having looked at the usage scenarios for distributed version control systems, the idea of people owning their branch only makes sense if you have really good (superhero) developers who are morally and ethically strong about writing good code. In an organization most of developers do not fall in that bracket. Also from an organization’s point of view, the whole notion of owning the source code ties very well with a centralized version control system. I agree with the post that SVN is in the right segment and should stick to its centralized paradigm – where its good at. Much much better than what CVS used to be :) .

  34. Masklinn says:

    May 1st, 2008 at 9:20 am

    Yet another mostly fact-less, mostly baseless, mostly knowledge-less article on DVCS. Couldn’t you just have stopped after the stupid tripe of your “Version Control and “the 80%”” article?

    Please, in the future, I beg you to stop trying to talk about DVCS, and stop trying to damage control for subversion, these articles are neither informative nor informed and it shows to anyone who’s ever tried to understand DVCS.

    Just ignore DVCS, and everything will be much better for everybody.

  35. Ben Collins-Sussman says:

    May 1st, 2008 at 9:27 am

    @Masklinn: you really thought my post was about DVCS? I thought it was about Subversion finding a niche. If you have real feedback, rather than just angry insults, I’d like to hear.

  36. Danni says:

    May 1st, 2008 at 10:14 am

    “Svn is a good implementation of a model of version control which is being rapidly left in the dust” – I don’t know if this person meant distributed vs centralized or branch and label vs. stream-based CM.

    I don’t think Svn has anything to worry about from Microsoft, but users may want to think about moving to something other than an interim solution to a branch and label architecture, only to require yet another tool swap in 2-3 years.

  37. David Glasser says:

    May 1st, 2008 at 11:25 am

    Sam: Yes, I’m aware that git clones are often smaller than Subversion HEAD checkouts. (I use git! I like git! Did anyone even read the quoted part about “I wouldn’t use svn for a new moderately sized open source project”?) The situations I’m referring to are ones where a HEAD checkout is too big for one machine. They exist. Seriously. (If you do a little research you might be able to figure out the main example I’m thinking of.)

    I mean, you say “It’s taken a while to arrive, mostly because most people just don’t need it.” about shallow checkouts. (And unless shallow checkouts also includes shallow (in the space dimension) cloning, it’s not useful here, by the way.) That’s *exactly* the point Ben and I are making. There are lots of fundamentally different use cases for version control. From the open-source perspective, “most people” don’t need to deal with projects that can’t be checked out onto a single machine, or projects with specific files that shouldn’t be readable by everyone. And if you don’t, then great! Something like git is going to work fine, and (ignoring the issues of portability, API stability, and usability, which I suspect can be fixed eventually) has many advantages over Subversion. But there are worlds where “most people” need exactly these features. And simply repeating “but these issues aren’t real because hard drives are big” is frankly missing the point.

    And are you sure about git modules / hg forest supporting true atomic commits across multiple repositories? Do you have a link to technical documentation about those features that explains how this is accomplished?

  38. David F. Skoll says:

    May 1st, 2008 at 12:47 pm

    @ Nath (23): We produce commercial software for a living and we use Git.

    We also happen not to use Java or C#. We want our userbase to do REAL, REAL work, so we use C and Perl.

    We switched away from Subversion to Git mostly because Git makes it so easy to branch, merge and cherry-pick. The “Distributed” part of DVCS wasn’t a particularly big deal for me. The clinchers were the speed and ease of merging.

  39. Vladimir Sizikov says:

    May 1st, 2008 at 12:59 pm

    Ben, interesting post, thanks. I’ve posted my (somewhat lengthy) response here: http://blog.emptyway.com/2008/05/01/response-to-subversions-future/

    In short, I strongly disagree that Subversion is better suitable to big projects than modern DVCS like hg or git.

  40. News all over: Subversion, OLPC and Second Life « Stefon’s Blog says:

    May 1st, 2008 at 1:04 pm

    [...] News all over: Subversion, OLPC and Second Life Together I want to present you three news entries in the world of free and open source software (FOSS). Subversion considers its future What role does Subversion — a “best of breed” centralized version control system — have in a world where everyone is slowly moving to decentralized systems? Subversion has clearly accomplished the mission we established back in 2000 (”to replace CVS”). But you can’t hold still. If Subversion doesn’t have a clear mission going into the future, it will be replaced by something shinier. It might be Mercurial or Git, or maybe something else. Ideally, Subversion would replace itself. If we were to design Subversion 2.0, how would we do it? [read more...] [...]

  41. Alan says:

    May 1st, 2008 at 2:01 pm

    The “we’ve replaced CVS, now let’s replace ClearCase” idea above is EXACTLY where it needs to go. If your primary work environment is military/security/gov’t and stationary server/workstations, DVCS as a concept doesn’t buy you anything. There’s already a commercial ClearCase killer out there called AccuRev. Looking at it for ideas on which paths to follow wouldn’t be a bad idea.

    And specifically regarding git, ( which I like, and I putter around with for projects at home ) corporations FREAK OUT at stuff like re-basing and fast forwarding pushes upstream. That destroy’s the audit trail, which might be the only thing saving your derierre for a Sarbains/Oxley audit.

    The thing to keep in mind is that like operating systems, ALL VC solutions suck. They each suck in different ways, and under different conditions, but they ALL suck. Your mission, if you are tasked to select one, is to find the one that sucks the least for YOUR environment, and matches your CM process the closest, so it can be customized to work the way you need to work.

  42. Masklinn says:

    May 1st, 2008 at 3:05 pm

    > you really thought my post was about DVCS?

    Seeing as you mentioned DVCS more than 12 times in one form or another one, yes it was.

    > I thought it was about Subversion finding a niche.

    Not exactly, it was about “waaah waaah subversion can still do things DVCS can’t”. In other words, damage control, and a bad one at that.

    > If you have real feedback

    On this post? Seeing as there are no facts, the only feedback I could give is that both points of the mail you quoted are either wrong or deeply misguided.

    > DVCS as a concept doesn’t buy you anything

    Sure it does, it buys you the same thing as it buys to everybody else, pretty much. Hell, Monotone probably buys you even more with its mandatory signed and checked commits.

    > corporations FREAK OUT at stuff like re-basin [...] That destroy’s the audit trail

    destroying the audit trail would require performing rebasing on stuff that’s already been committed/upstreamed, which is more than frowned upon (as it breaks other people’s repositories) and could trivially be prevented by using hierachical trees of repositories (which is trivial to do). Rebasing is mainly a tool for linearizing one’s changes against a repository’s head instead of having to create pointless merge changesets, it’s not something you’re supposed to use on patches already upstreamed.

  43. Matt Brubeck says:

    May 1st, 2008 at 3:12 pm

    I worked for several years in an environment where the entire source tree could not fit on a single development host. At least in my workplace, I personally don’t think atomic commits across arbitrary parts of the tree were as necessary as some people seemed to assume. They’re definitely useful if you have them (which we did), but if we didn’t have them I think we’d have adapted with very little effort.

  44. Dave says:

    May 1st, 2008 at 3:19 pm

    @James Roper: 100s of

  45. Ben Collins-Sussman says:

    May 1st, 2008 at 8:18 pm

    > it was about “waaah waaah subversion can still do things DVCS
    > can’t”. In other words, damage control, and a bad one at that.

    You got me! Clearly the Titanic is sinking, and you have uncovered my
    desperate attempt to persuade users from jumping ship. I should drop
    my ruse and finally acknowledge that DVCS is clearly superior to
    centralized is every conceivable context, for every conceivable class
    of users. One size fits all, right? What was I thinking?

    > Seeing as there are no facts [...]

    Other than a giant graph of hard numbers showing exponential svn
    adoption rates? When you’re ready to bring similar data to the table,
    let’s chat.

    What continues to amaze me is that while Subversion developers keep
    trying to have level-headed discussions about how different systems
    shine or stutter in different situations, these attempts at objective
    analysis keeps getting identified as “desperate weakness” and “damage
    control” by arrogant DVCS zealots. The Subversion community has
    always had these debates, even before we had written one lick of
    code. Subversion developers have *always* been eager to
    self-criticize, judge tradeoffs in design, and adapt to new
    situations. If all the chest-thumping githeads I’ve met truly believe
    that they’ve found the One True Solution and that “everything else is
    stupid” (to quote Linus), then their delusion is too deep to even take
    part in the conversation.

    Eesh. I should know better than to feed trolls.

  46. uglychart.com: a blog about stocks » Blog Archive » links for 2008-05-02 says:

    May 2nd, 2008 at 12:33 am

    [...] iBanjo » Blog Archive » Subversion’s Future? (tags: programming development subversion) [...]

  47. jgg says:

    May 2nd, 2008 at 1:17 am

    Ben,

    I’ve been using DVCS in a commercial environment for about 5 years now. We moved from CVS to BitKeeper which was a very significant and positive change. Recently we have moved from BK to git, which is a fairly lateral move.. I understand BK is doing OK in the commercial world and they tout significant advantages over the other big vendors, most of which are real.

    In my experience the issues people have been mentioning were not a problem for us. We identified them and adjusted our processes. Things have worked out very well.

    Some observations I will share based on this experience:
    - For us the switch did need some training and there was some hand wringing and change to developer process but overall it went pretty smooth. An interesting benefit was that people started doing whole-tree builds rather than only builds of their one little bit (bk does not allow partial tree checkout, so this became mandatory). This little thing greatly reduced the build breakage rate :)
    - We did spend some time speeding up the whole tree build process. Optimizing makefiles, letting make -j4 work better, etc, etc. This was again overall positive. The project size was such that a full tree build on NFS was about

  48. Michael Tsai - Blog - Subversion’s Future? says:

    May 2nd, 2008 at 9:31 am

    [...] Ben Collins-Sussman: [...]

  49. “Two Types of Programmers”… « JP’s Web Place says:

    May 3rd, 2008 at 6:14 am

    [...] Facendo un giro su LWN mi sono imbattuto in un interessante post in cui si parla del futuro di Subversion, un famoso programma (”tool”) per il controllo versione. [...]

  50. Troels Arvin says:

    May 6th, 2008 at 12:56 pm

    I don’t plan to leave Subversion. I actually like Subversion a lot:
    – Great cross-platform support
    – Lots of optional add-ons and possibilities for integration with other software configuration management tools
    – A track record which makes me sleep well at night
    – Great documentation, including good books

    What I’m missing in Subversion is actually even more aspects of centralization:
    – LDAP-integration in the svn access configuration files, so that groups may refer to groups in an LDAP tree
    – Ways to distribute policies like “.html files should automatically be marked with text/html context type”, or “.c files should automatically get this and that svn:keywords

    Oh, and this would also be helpful:
    – A way to handle charset conversions on the fly: If my locale is UTF-8 but the repository’s general charset is Latin1, I would like to be able to tell Subversion to automatically convert my checkouts to UTF-8 but convert my commits back to Latin1 when committing

  51. Stephen Baynes says:

    May 9th, 2008 at 3:45 am

    The comercial world needs aspects of centralized and distributed CM.
    Projects are often multsite, multi team. They may involve external partners (I have seen Git and Mercutirial used in somecases) but sometimes communication with these is restricted to email only. Separately produced IP that is integrated into many products is common – something the open source tools have not yet tackled. On the other hand there are usually many developers at one location and data sizes (particually once CAD data is added) are lage. 10GB workareas are not rare and I have seen one that was a quater of a Terabyte. For this you have to have link based workareas to a shared cache. Most of the tools targeting open source assume one developer per location. On the other hand access controls need to be good – data may need to be replicated between repositories granting different acceses. Most of this streatches the best comvercial CM tools too.

  52. Kamil Kisiel says:

    May 9th, 2008 at 11:47 am

    I’m sure SVN is not going anywhere in the near future. It’s far too valuable of a tool.

    Not only is it necessary in order to provide some form of central auditing of the source, but it’s also far less confusing. Many developers, even in a highly technical organization like where I work, have problems dealing with the more complicated aspects of source control. Even *I* find git somewhat confusing, I can’t imagine throwing it at the people here. Furthermore, SVN integrates nicely with tools like Trac, which is a complete godsend for our environment.

    Troels: I’ve written a script that pulls LDAP group members and places them in the authz file. Please feel free to contact me at kamil@kamilkisiel.net if you are interested in a copy.

  53. Pascal Varet says:

    May 9th, 2008 at 12:30 pm

    @Ben:

    Hi Ben,

    Thank you for this interesting article! While there has been a lot of posting here already, I would still like to chime him and thank your level-headedness, the clarity of your vision, and that way you have to welcome discussion of Subversion’s flaws without antagonism against other solutions.

    I hope the twitchy zealots and trolls that have unfortunately flocked to your post will not discourage you from this approach, and in the name of the silent mass whose use cases require centralized source control, I would like to humbly thank you for providing us with such a good tool for this purpose.

    PS: The anecdote about how Karl and you received the delta editor design from Jim Blandy is thus far among my favorite chapters of the ‘Beautiful Code’ book, not only for its excellent software design literacy, but also, and perhaps mostly, for its deep humility.

    @Troels Arvin says:

    > – LDAP-integration in the svn access configuration files, so that groups may
    > refer to groups in an LDAP tree

    Excellent point. We solved it here with a small Python script that automatically generates the svnpolicy file by polling the LDAP directory, and runs from cron; it ended up working much more smoothly than I had anticipated.

    > – A way to handle charset conversions on the fly:

    I would like to second this wish. Although the core issue really is that the Linux filesystem thinks of filenames as *bytes* (with no explicit encoding information) as opposed to characters, causing all kinds of problems when you can’t tell what the LC_CTYPE was at the time the file was created, a workaround at SVN’s level would be sweet. This is probably the number one issue my users get.

  54. Stephan Wehner says:

    May 9th, 2008 at 12:36 pm

    I would just think about how to make subversion compatible with distributed systems. Just because subversion sits on one server doesn’t mean it can’t participate in a distributed system. Might sound strange, but that’s would I would try to work out.

    Stephan

  55. Jeff says:

    May 9th, 2008 at 12:47 pm

    I’m suprised that only two previous comments have mentioned SVK. From http://svk.bestpractical.com/view/HomePage
    “svk is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.”
    I’ve used SVK extensively. It provides 90% of the functionality of other DVCS tools, on top of SVN. So you can have your cake and eat it to (mostly).
    It’s not a panacea though. First of all it’s got a very bad case of CPAN dependency hell. If you don’t mind installing it with the cpan shell, or if a native package already exists for your platform, then no problem. If you are trying to roll your own native package, welcome to hell.
    I work for the Scripps Institution of Oceanography and I have to maintain syncronized source code and configuration information for a shoreside office and 4 ocean going research vessels, with very slow and unreliable internet access, and that might only be in home port once every 3 years. We’ve opted to go with Mercurial instead of SVK because of HGs ability to sync any repository with any other repository and dump changesets to files. EG I can clone a repo from the shore server onto my laptop, then to the ship’s main server, then my buddy can grab it from there, and we can all push/pull in whatever sequence is most convenient at the time. When it comes time to push our changes back to shore, I can dump the changesets to an HG changeset file, BZIP and RSYNC it. Alternatively, I can just bring the repo home on my laptop and push the changes to the shore server once I’m back in the office.
    This is much more convenient than SVN/SVK where a large commit might take an hour over the satellite, and if it breaks then I have to start all over again because it’s atomic and there’s no way to resume a partial commit, or an update for that matter. Our satellite links rarely stay up for an hour without interruption. I know SVK can dump out a patch set, but then I lose history. The bottom line is that SVN/SVK just doesn’t work over slow, unreliable links.
    Granted my environment is probably highly unusual.

  56. Adam Schrotenboer says:

    May 9th, 2008 at 1:11 pm

    It is not necessary to pull ldap group members anymore, at least with Apache 2.2. Instead, try this.

    LoadModule authnz_ldap_module modules/mod_authnz_ldap.so

    Order deny,allow
    AuthType basic
    AuthName LDAP
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative On
    AuthLDAPURL “ldap://ldap.lan.example.com/cn=users,dc=example,dc=com?uid?one”
    AuthLDAPGroupAttribute memberUid
    AuthLDAPGroupAttributeIsDN off
    # these are ‘OR’ requirements, not ‘AND’
    require ldap-group cn=specialgroup,cn=groups,dc=example,dc=com
    require ldap-group cn=softgroup,cn=groups,dc=example,dc=com
    # 1026 is ‘specialgroup’
    # 1037 is softgroup
    require ldap-attribute gidNumber=1026
    require ldap-attribute gidNumber=1037

  57. Adam Schrotenboer says:

    May 9th, 2008 at 1:13 pm

    Oops, didn’t realize that would be interpreted as a tag.

    LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
    <Location />
    Order deny,allow
    AuthType basic
    AuthName LDAP
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative On
    AuthLDAPURL “ldap://ldap.lan.example.com/cn=users,dc=example,dc=com?uid?one”
    AuthLDAPGroupAttribute memberUid
    AuthLDAPGroupAttributeIsDN off
    # these are ‘OR’ requirements, not ‘AND’
    require ldap-group cn=specialgroup,cn=groups,dc=example,dc=com
    require ldap-group cn=softgroup,cn=groups,dc=example,dc=com
    # 1026 is ‘specialgroup’
    # 1037 is softgroup
    require ldap-attribute gidNumber=1026
    require ldap-attribute gidNumber=1037
    </Location>

  58. Dave McDave says:

    May 9th, 2008 at 1:43 pm

    Probably a bit of a crazy thing to say but, maybe subversion should just keep doing what it’s doing. There are lots of non-technical reasons why people use subversion as verses distributed systems, some that come to mind (and, in some cases, apply to me) are things like:

    *. It does the job.
    *. It’s robust.
    *. I understand how it works.
    *. Maybe I want one central version.
    *. It requires minimal set up (can run ad-hoc, from filespace or over SSH w/o any servers).
    *. I like it.

    For what I want to do (i/c things like running a private, personal code repository) it’s just fine. I could spend the N hours picking $THE_BEST_DVCS and getting as familiar with it as I am with svn, but, hey, you know what, I’d rather spend that time doing real work, or with my partner.

    I guess the base line is, that subversion is becoming infrastructure. It changes the appeal of it as a piece of software, it may not be breaking much new ground, but it’s becoming really important to lots of people. It’s transitioning into a new phase of the software lifecycle and some of the head scratching and arguing about direction is because of that ‘growing up’. For example, look at Apache and the amount of hassel they’ve had moving people off the 1.3 series to the (technically much stronger) 2.X series.

    So, yea, keep up the good work guys. Please. We kinda need you to…

  59. Jeff Ebert says:

    May 9th, 2008 at 2:23 pm

    I use centralized revision control in a corporate environment for chip design. Working area size is a big concern for us. The assumption that disk space is cheap is simply not accurate. Fast, backed-up disk space is not cheap, and that is what we use in a corporate environment. We have shared compute resources that are networked to shared filers (net apps). We are going over a very fast, very reliable network for every file access already.

    So, obviously, the biggest problem in using subversion in my work is the text-base penalty. Distributed version control systems are worse, I would assume, because you are not sharing the repository with other people. Therefore, our only options seem to be CVS and Perforce. Without the text-base penalty, I know of a large number of chip designers that would have switched to SVN a few years ago.

    I do use subversion for small hobby projects, but I cannot justify switching to it at work. If the project does begin to focus on the needs of typical corporate users, then I think the disk vs. network assumptions will need to be revisited.

    Thanks for your hard work!

  60. Karl Fogel says:

    May 10th, 2008 at 2:27 am

    Yeah, we’ve got to get that text-base penalty lowered or made optional eventually… If we had an optional ‘svn edit’ command (meaning: “I’m about to edit this file”), then that command could first copy the working file to hitherto-nonexistent text-base, doing any eol or keyword subst along the way, of course.

  61. Paul "TBBle" Hampson says:

    May 10th, 2008 at 11:59 pm

    Certainly, for my workplace (a video games development company) our head checkout is in the order of 15gB (30gB with .svn folders -_-) but each developer needs all that to be able to test changes etc.

    The _big_ advantage of SVN for us however is that it lets us give limited read and commit access to third-parties (outsourced work) without giving them either the ability to write things they should not be able to, nor read things they should not be able to (eg things we do not own ourselves).

    On the other hand, when workflow permits, I use git-svn so I can use git for my work, and then push it back up to the SVN server as appropriate. (Workflow permits here means Linux-side work. git under windows just doesn’t rock my pants successfully. Also, current project has checkin-requirements that git-svn would not integrate well with. >_<)

    The other big advantage of SVN is that it has a Windows client that the non-technical people (artists, producers, game designers etc) can use without significant support. I’m hoping one of the Mercurial windows frontends comes through here, although _I_ would like a git-svn windows shell addin, personally.

    Linux.conf.au 2008′s Gaming Miniconf has a video in which I ramble undirectedly about the reasons we can’t yet move from SVN. It’s the FOSS In Commercial Games video.

  62. Troels Arvin says:

    May 11th, 2008 at 6:15 am

    @Adam: I know that Apache can handle LDAP authorization. That way, you may give all-or-none access to a repository. However, there is no obvious way to specify that LDAP group “foo” is the only group which may access /some/sub/tree of a repository.

    (I prefer to have one big repository, so that history doesn’t get lost if a file is moved/copied/… betweeen repositories.)

  63. Web Development Stuff, Freedom Stuff : Appeal Democrat says:

    May 14th, 2008 at 10:40 am

    [...] iBanjo » Blog Archive » Subversion’s Future? I have to say, after using Mercurial for a bit, I think distributed version control is pretty neat stuff. As Subversion tests a final release candidate for 1.5 (which features limited merge-tracking abilities), there’s a bit of angst going on in the Subversion developer community about what exactly the future of Subversion is. Mercurial and Git are everywhere, getting more popular all the time (certainly among the 20% trailblazers). What role does Subversion — a “best of breed” centralized version control system — have in a world where everyone is slowly moving to decentralized systems? Subversion has clearly accomplished the mission we established back in 2000 (”to replace CVS”). But you can’t hold still. If Subversion doesn’t have a clear mission going into the future, it will be replaced by something shinier. It might be Mercurial or Git, or maybe something else. Ideally, Subversion would replace itself. If we were to design Subversion 2.0, how would we do it?   Last week one of our developers wrote an elegant email that summarizes a potential new mission statement very well. You should really read the whole thing here. Here’s a nice excerpt:   [...]

  64. Monkeyz.eu / Gestionnaires de configuration: Récapitulatif des systèmes distribués says:

    May 22nd, 2008 at 3:21 pm

    [...] Post de Ben Collins-Sussman (développeur de Subversion) sur ces systèmes distribués: http://blog.red-bean.com/sussman/?p=90; [...]

  65. Matt Craighead says:

    September 9th, 2008 at 2:53 pm

    I totally agree with previous comments such as “the corporate world (especially someplace like Google or Apple with loads of IP to protect) will stay on a fundamentally central model.” And I’ve definitely worked on a number of projects where it is totally impractical to keep an entire working copy on your own local drive, to say nothing of an entire repository history. (And *two* copies of every file? That’s just crazy talk!)

    I think DVCS has been overhyped as a solution. Yes, it’s a problem that access to a centralized server over a WAN is slow. Yes, it’s a problem that you have to create an actual branch on the centralized server if you want to checkpoint some temporary, unfinished work in progress. But is the answer to mirror the entire repository on your own local disk? Of course not!

    So what’s the real answer? I think it’s a combination of a centralized system with tools to help enable better distributed development. Admittedly, I’m not exactly a disinterested party in this discussion, but the answer, I think, is something along the lines of my company’s tool Cascade. You don’t have to throw away or migrate your existing Subversion or Perforce repository, yet you get many of those same benefits that a DVCS offers through Cascade’s caching system, proxy server, and “checkpointing” mechanism — plus a bunch of other cool stuff.

  66. Subversion: Sistema de control de versiones - Tutorial y material | Picando Código says:

    October 20th, 2008 at 5:23 am

    [...] distribuidos de control de versiones como Git, Bazaar y Mercurial, y la tendencia de Subversion a seguir siendo centralizado – The Future of Subversion. También te puede interesar investigar sobre sistemas de control de versiones para bases de [...]

  67. Mike says:

    April 7th, 2009 at 12:41 am

    some of us at work are using git as a sandbox organizer.
    but really, we are using it to hide our early-stage work.
    this is a psychological issue, not a technical one – and
    maybe its not a good idea.

    we depend upon Subversion for our Central Authoritative Repositories.

  68. BSD says:

    May 4th, 2009 at 1:32 pm

    I think you are seeing this type of approach emerge:

    A team of 10-12 people checks out something from svn and convert it to hg/git whatever and start hacking on it – collaborating “outside” svn using dcvs tools. When they have done enough work to make their changes significant enough to check back in to the “core repository”, things are cleaned up and having used hgsvn or gtsvn conversion to start with (leaving the subversion check out intact) they check the changes things back in to svn. You can use hg log and other local tools to help build a well documented commit message to put back into the subversion repo. Some care is required to avoid checking in any files/directories that are hg or git specific (use ignore). Used together SVN and DCVS can make the canoncial subversion repo less busy and messy and can keep multiple modes of collaboration “on track” and working together.

    One comment on *big* projects: the freebsd project uses p4 and svn together – it’s a mess and not documented well but meets a need. I think if subversion documented how to do this nicely kind of thing well with hg and git … and or made it possible to use svn *itself* in a semi-distributed kind of way (local history etc) it would be great.

    A spiffier nicer builtin web viewer/publisher (ViewVC is a little olde-fashioned) that could work from inside checked out versions of a project (sort of like “hg serve”) would be nice too.

    http://pypi.python.org/pypi/hgsvn

  69. Catherine says:

    June 19th, 2009 at 12:38 am

    I would recommend SCM Anywhere, which is a SQL Server-based software configuration management (SCM) tool with fully integrated version control, bug tracking and build automation.
    http://www.scmsoftwareconfigurationmanagement.com

  70. David Gay says:

    September 21st, 2012 at 2:52 pm

    Best take I’ve heard on the future of VC.

  71. Paas and NoSQL are coming so you better get ready - Platform as a Service Magazine says:

    September 21st, 2012 at 4:33 pm

    [...] Subversion is done and you will eventually be using git. People can argue about this all they want but the flow of technology seems pretty clear to me now that we will all be using git within the next couple of years. So, as a developer, you are faced with two choices – start getting on board with git or ride subversion into the sunset. [...]