Subversion status and future (what to expect from SVN 1.7)

By neokrates, written on June 14, 2010


  • Join date: 11-30-99
  • Posts: 224
View Counter:
Rate it
  • What are the 3 most important SCM/VCS features for you?

    View Results

    Loading ... Loading ...
  • bodytext bodytext bodytext

The future of subversion. I was lucky to visit the “Subversion day in Berlin 2010”. Subversion developers talked about the current state of SVN and things to come. Discussed known problems with this tool and features it needs most. How will SVN compete with distributed systems like GIT or Mercurial, what is its role in the Enterprise.

The information source is “Subversion Day Berlin 2010, 11 June 2010”.

⚠ When SVN 1.7 is to be released

Due to the major changes in 1.7. there is no deadline yet. But it is to be expected between September and December 2010 (Julian Foad of WANDisco)


What is new and what will change in 1.7


NEW: WC-NG, working copy – next generation

Is a major change in subversion. The .svn directories will be eliminated in favor of one big .svn directory in Working Copy root.

FASTER: WC-NG rename tracking, first step

With implementation of WC-NG, rename tracking will be implemented (partially). The intention is to reduce or eliminate Tree Conflicts, ensure better merge experience.

FASTER: WC-NG less or no time before the local subversion operation starts

Subversion seems to sleep for something between 10 sec and 2 minutes after you enter svn command (svn info, svn up, etc…)
That occurs because each .svn metadata directory will be read from the local disk first. That will no longer be the case, after WC-NG is introduced.
👉 On older hardware systems with “problematic” hard discs, subversion before version 1.7. would go through directory tree hence causing major slowdown.


Better handling of HTTP Requests and responses will reduce the number of Round Trips. Lesser requests from the client to the server and back will be needed. That should boost the SVN performance


Improved SVN Patch functionality.

IMPROVED: Renaming

Renaming local files and directories is expected to be more:
– easy
– reliable (human friendly)
– track-able

– Mr. J.Foad of WANDisco


NEW: Sparse checkouts

Checkout only selected files and directories within a hierarchy.


Merge is considered to be a central feature of SVN. Currently SVN Team sees many problems, some of which are related to the CVS beginnings of subversion. There are also some new Merge types to be expected in 1.7

NEW: Catch-up merge

Catch-up merge, also called, re-basing a branch. Is a method of getting all the changes from the main code line into the current branch (thus branch will “get new base”).

NEW: Re-integrate merge

Will merge all changes from branch (code line) into the trunk.

REMOVED: Spread metadata (.svn dirs)

There are many problems with .svn sub-directory in each directory of the working copy. Such structure is a legacy from .cvs. With SVN 1.7. it will be obsolete. There might be an upgrade command which transforms the local copy into svn 1.7 compatible format.

IMPROVED: Handling of tree conflict problems

In earlier SVN versions this problem existed but had no “official” name. Up 1.6 (if I am not mistaken) it is a known problem and SVN team tries to solve it. But fails in many cases.
Tree conflict problems occur i.e. then the working copy is missing a part of the local directory tree. It may be moved, renamed, meta-information may have being lost. As the consequence, multiple SVN operations will fail. WC-NG will attempt to fix tree conflicts by centralizing the meta-data. (no .svn dirs in each directory)


SVN vs. GIT , Mercurial and Bazaar


1. Some distributed VCS features in SVN

Some features are to be implemented in Subversion and might be introduces in 1.7:

  • shelving/unshelving;
  • distributed VCS storage;
  • option to take your SVN repository home and work without a central server (not sure here, please let me know if I’m not mistaken);


2. SVN vs. Bazaar. Better rename

SVN will learn from Bazaar renaming approach and integrate something similar.

3. SVN vs. GIT vs. Mercurial. Speed ‘yes’, fully distributed ‘no’

The major advantage of GIT and HG over SVN is speed, and that is acknowledged by SVN Team as well. Speed comes from the highly optimized local copy of these VCS’s. That is the nature of distributed VCS, you work with the local repository and it is much faster.

SVN will not try the same approach. Speed will be optimized and may become comparable with GIT and HG (SVN developers pointed out that they see it as possible). But there are no plans for SVN to become a distributed SCM.

4. SVN can handle teams, distributed all over the world

One major advantage of distributed SCM’s is that teams in different places can use version control without speed loss. With SVN it may become a problem, especially with teams spread all over the globe. Mr. Heinold of CollabNet argues that SVN with following setup can overcome latency problem:

  • first precondition is a good network connection between working places;
  • then, master and slave subversion servers should be setup. The slave server (maybe somewhere in India ) will run with “write through/read through” setting (SVN server config, possibly only in apache mode). Master (for example in USA) will get the changes from all the slaves and slaves will get updates from the master. From the local user point of view the interaction occurs with the local server. That should minimize any speed loss or latency.


5. SVN is secure and keeps things simpler

The first scenario might be a nightmare of any enterprise. Someone takes all the code and can use it anywhere. That is particularly easy with GIT or HG. Cloning whole repository is what they are made for. Subversion can prevent that scenario because all data are stored centrally.

Second problem is that the GIT project can be cloned limitless number of times. in fact, it becomes so easy that everyone does it. The problem is then, how to find the “right” version of the project, the one you need.


General strategy of Subversion development

✔ API backwards compatibility

With the new releases API’s will not be broken. Older clients will still work with new svn.

✔ Enterprise orientation, subversion will always be centralized

Centralized nature of the subversion will remain. That is what most enterprises expect from VCS tool. It allows centralized management of the users and all the code. The distributed VCS system approach like GIT might be a risk for the enterprise (but maybe not for the open-source community)

✔ Get all the available features working

SVN Team sees that many features of svn are not 100% usable. Major focus of future releases is not to implement as much as possible but to make all what is already there work perfect.

✔ SVN is independent Open Source Project

SVN started at Collabnet and then had its own legal entity, called Subversion corporation. Now it is an apache project. The major idea of incubating into Apache project is “to remain truly independent and legally protected Open Source Project”

✔ More Speed

SVN developers see the gap between SVN and systems like Git or Mercurial (HG)

Overcoming this gap is considered to be possible and 1.7 should already improve speed in many ways.

Other current issues with subversion

⭐ Many big enterprises base there software life-cycle on SVN. Mr. N. Schellingerhout from Phillips Healthcare Devision, whom participated in the conference, stated that shorter SVN Lifecycle would be of advantage. Release cycle of subversion might have become too long. It was shorter in the beginning, but not 1.5 and not 1.7. It is considered to be a risk factor.

⭐ Merge is still a problem. For example Phillips Healthcare uses the alternative tool which replaces native SVN merge. It is called truemerge and may be found here: The members of SVN development team argue that truemerge might cause problems. For example, that might be a problem that truemerge makes assumptions about the working copy state (which allows cleaner automatic merge). That assumption could in some cases be incorrect (that was a matter of discussion in the conference).

⭐ SVN still has problems with Merge Tracking. That is a particular issue for big enterprises which entertain many code lines (branches, tags etc…) and must have history of any change and merge.

⭐ Consistency problems with svn server have been known in older releases and are still considered to be a risk. After some server side crashes subversion seems to loose the data. That does not occur often and is repairable (Data backups), so no data loss should occur.

Be Sociable, Share!

LEARN MORE (amazon bookstore)


Be Sociable, Share!

4 Responses to “Subversion status and future (what to expect from SVN 1.7)”

  1. Nathan Brown says:

    Thanks for the info. The status update is very useful as we wait, sometimes impatiently, for WC-NG.

    • WC-NG promises to be the next big thing. In 1.7 the core of it will be implemented, replacing distributed .svn directories. Me, i expect less merge problems, much more predictable and explainable behavior( lesser tree conflicts, better renames etc) and speed boost (no need to go through hundred .svn’s is great)

  2. Carlos Galassi says:

    Very good news about svn, and maybe the end of problems to do a CleanUp very often ;-) Thankx

  3. Adrian says:

    Thanks for the info.

Leave a Reply