Tag Archives: version control

Subversion 1.7 released: just one .svn directory per working copy

Yesterday saw the 1.7 release of Subversion, the widely used open source version control system. It is a significant release with many new features, bug-fixes and performance improvements, and I suggest reading the release notes or complete change log. One thing to highlight is that the default working copy metadata storage is now a single sqlite database per working copy, rather than a .svn direction containing metadata in sub-directory.

I upgraded my TortoiseSVN, which is already updated to 1.7, and tried upgrading one of my own projects. Here is the .svn folder before the upgrade:


and after


Those pesky .svn folders can be a nuisance so this is a welcome change, although there is a downside as the release notes warn:

It is not safe to copy an SQLite file while it’s being accessed via the SQLite libraries. Consequently, duplicating a working copy (using tar, cp, or rsync) that is being accessed by a Subversion process is not supported for Subversion 1.7 working copies, and may cause the duplicate (new) working copy to be created corrupted.

Subversion is less fashionable since the advent of distributed version control systems like git and mercurial; though for corporate development Subversion remains popular because a centralised system is easier to control.

WANdisco’s Jessica Thornsby has a helpful post on the new 1.7 features more details on the benefits of the new working copy metadata managements system.

Real-world Microsoft Team Foundation Server: Not very good, says ThoughtWorks

I spoke to Sam Newman, who is European Continuous Delivery Practice Lead at ThoughtWorks, a software development company. Needless to say, we talked extensively about Continuous Delivery and I will be reporting on this separately; but I was also interested in his comments on Microsoft’s Team Foundation Server (TFS).  He told me that ThoughtWorks teams often end up working with it at their .NET clients, but it is problematic. In one case, he said, 6% of productive time was absorbed dealing with TFS.

What was the problem, performance, bugs, features lacking?

When we’ve looked at the problems we’ve had, a lot of it unfortunately comes down to the version control system. It’s not very good. It’s slow, you can’t do rollbacks, sometimes things go missing, you get locks. When we talked about 6% of time, they were things like waiting for a solution to expand in Visual Studio. A lot of those issues are in the version control system.

A frustration is that you cannot use TFS with any version control system other than its own.

Every other build server in the world, from Anthill to Go to Cruise Control to Hudson, you can put in at least 10 version control systems. In TFS they are all coupled. So you can’t take the version control and point it at Subversion. That might resolve a lot of the issues.

Why is TFS so widely used? It is because it comes in the box, says Newman.

I can’t think of a single client that wanted a tool, went out into the marketplace, and selected TFS because it is the right tool for them. Most clients use TFS because it comes with their Enterprise MSDN licence.

I have tried TFS myself and found it pretty good; but then I am just testing it on small projects as a solo developer, so it is hard for me to replicate the experience of a real-world team. You would have thought that performance issues, such as waiting ages for a solution to expand in Visual Studio, could be solved by tracing the reason for the delay; but apparently this is not easy.

This is anecdotal evidence, and of course there may be plenty of TFS installations out there that work very well; I would be interested in hearing of counter examples. I am also not sure to what extent the problems apply to all versions of TFS, or whether there is improvement in TFS 2010.

Newman recognizes that anecdotal evidence is not much use: he says ThoughtWorks is trying to collect some solid data that can be used both to discuss with clients making version control and build system choices, and with Microsoft.

Performance is a feature, and makes a large contribution to user satisfaction. The first release of Outlook 2007 was extraordinarily slow in some setups, and I remember the pain of clicking on a folder and then waiting tapping my fingers while it thought about expanding. It sounds like some TFS users are having a similar experience but in Visual Studio.

Rumblings in the Subversion community as WANdisco claims to be “shaking it up”

Subversion is an open source version control system used by developers to manage source code; it was an improvement over CVS which it to some extent replaced. Everyone loved it until Linus Torvalds came up with an alternative called Git which is better suited for the distributed development typical of large open source projects like Linux. Now everyone loves Git – with a bit of love left over for another distributed system called Mercurial – and Subversion has become a tad unfashionable, though still widely used.

David Richards is president and CEO of WANdisco, which has a source code management suite based on Subversion. He has announced his intention to “shake up Software Change Management” by fixing Subversion’s weak points. He writes:

Enough is enough. Subversion gets a lot of criticism due to the shortcomings of branching and merging, especially when compared with GIT and others, and we simply don’t have the time to debate whether or not this should be done when it clearly should be.

Why so combative? Well, there a few curious points here. Subversion was originally sponsored by Collabnet, which has its own ALM (Application Lifecycle Management) suite which uses Subversion, as well as a free product called Subversion Edge which packages the official open source release with some convenient tools. Subversion did not become a top-level Apache project until February 17 2010. According to Richards, there is now competition between commercial companies to be seen as the primary Subversion sponsors. In a blog post today, Richard refers to “commercial interests that are dependent on the perception that they are the ones developing Subversion” and adds:

We also believe it’s unhelpful when certain unscrupulous committers decide to commit trivial changes in large files to simply get their stats up.

Richards feels that Subversion development has stagnated:

Didn’t the community just announce a road map? Yes they did, but that’s pretty much all that happened (and that really pisses us off.) The commit logs (code committed by developers to the project) tell the real story. We are not happy with the volume, speed or participation on the project right now. Blogging, or answering questions on user lists are important, but so is writing source code.

The not-so-veiled threat in Richards’ post is that he will fork Subversion if necessary. He says “we don’t believe that [forking] is necessary” but when he adds later that “we would prefer that this be a community effort” it seems clear that forking is an option.

Richard says that WANdisco held a “summit” of companies with a vested interest in Subversion and that there was “a common theme: branching and merging must improve.”

Personally I like Subversion though it is also obvious that Git is superior for many projects. Richards does not help his cause by accusing “GIT Fanatics” of being unfair in their criticisms.  The comments to his post are worth reading, for example:

I used Subversion without prejudice over CVS because it was better. Today I use Git without prejudice over the other two. Git has changed how I work. I use facilities in Git that are not possible with Subversion or CVS.

Developers who take this view will not care much now about Subversion. Still, a lot of people still use it, probably many more than those who use Git, and improvements would be welcome. I am not clear though why the CEO of WANdisco is sounding so embattled, or what politics or difference of opinion is dividing the Subversion community, and would like to hear more about it.

Update: clarified that Subversion Edge is a free product

Update 2: The Apache Software Foundation replies in a blog post:

WANdisco’s false implication that it is in some kind of steering position in Subversion development discredits the efforts of other contributors and companies … we welcome WANdisco’s involvement in Subversion, and failure on WANdisco’s part to address the above concerns will have no effect on the acceptance of technical work funded by WANdisco. We simply felt it necessary to clarify WANdisco’s role in Apache Subversion, for the benefit of our users and potential contributors.