Subversion status and future (what to expect from SVN 1.7)By neokrates, written on June 14, 2010
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.
FASTER: HTTP v2
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
Improved SVN Patch functionality.
Renaming local files and directories is expected to be more:
- reliable (human friendly)
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:
- 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”
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: http://trumerge.open.collab.net/. 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.
LEARN MORE (amazon bookstore)
INCOMING SEARCH TERMS