Blog - /Tech

There was a Google Tech Talk about Google Sky at Purdue today, which also doubled as a recruitment effort. I noticed that Brian Fitzpatrick, a Subversion and Apache developer was there, so during the Q&A afterward, I posed the following question to him:

Can you comment on any plans to add distributed features to Subversion?

He started the reply by listing the features that would be gained by making Subversion distributed, and that there were indeed (IIRC) plans for this in some future release of Subversion. I was impressed that he was up-to-date in this area, and that was able to list the major benefits. Alas, he then lost me by saying something along the lines of: a downside of distributed version control systems is that they discourage people from contributing their changes back to the main project (note: this is not an exact quote, just a remembered impression). I completely disagree.

The prestige factor of getting your changes into main is always there, unless you just want to fix things up real quick for your company. And even then, people could easily keep their own hacked version up-to-date without contributing back to the central tree, since they don't need to query or keep track of history, just re-base their fixes against new versions of the software. Centralization of the main project gains you absolutely nothing in that regard.

In fact, you lose big:

1. Casual contributors who don't have developer access to the project are screwed. Any changes they want to commit have to be constantly re-based against a changing development tree.
2. Main developers have to constantly have a high-speed Internet connection in order to do any useful development. Also, if they want to do fun things like tracking a function that has moved across several different files, they are completely SOL since they have to hit the network for that information. Many more inconveniences exist; the point is made.

In the response, it was then mentioned that there is an expectation to review any changes that are made with at least one other person. Subversion does not strike me as a good tool for that. A private branch would be the first thing that comes to mind, but at the time of this writing, the latest Subversion release sucks at merging changes and preserving merge history, in case you plan to merge changes back to that branch. With git, on the other hand, you could have a real dedicated review branch, potentially shared by only two people, which can be easily merged into main, and changes from main can be easily merged back.

At the time, this seemed to say to me, "Well, this feature is completely useless, but since people are clamoring for it, and to save face, we'll solder it on, in hopes that people who really care about it will improve it." I realize now that this was somewhat of a hasty conclusion to draw, given the time constraints and how off-topic my question was for this Q&A session. I remain rather pessimistic, however, about the ability of future releases of Subversion to handle distributed features well, particularly if they plan to draw heavily from the svk project.

Update

I realize now that the initial entry came off as a bit more acerbic and personal than I really wanted it to be. and somewhat lacking in civility, so I am taking the liberty of adjusting the tone of a few paragraphs. I didn't properly convey that I was very impressed with him for knowing the benefits to distributed version control, just disappointed at ending on that note. Apologies to Brian for taking his response out of context.