![](https://d15shllkswkct0.cloudfront.net/wp-content/blogs.dir/1/files/2013/06/subversion-logo.png)
![](https://d15shllkswkct0.cloudfront.net/wp-content/blogs.dir/1/files/2013/06/subversion-logo.png)
Everyone talks about Git and Mercurial, but many developers continue to rely on the Apache Subversion version control system. According to the Apache Software Foundation (ASF), Subversion is the most popular and most widely used open-source version control system.
Despite the development and popularity of decentralized systems such as Git and Mercurial, Subversion is very popular in commercial companies and projects that use a centralized approach to version control and configuration management software systems.
The Foundation yesterday presented the new 1.8 version of the source code control tool. In preparing a new release Apache focused on the adaptation of Subversion use in a corporate environment, simplify administration and automation to perform common operations. According to the Apache developers, the new version contains a limited number of changes that are visible to the normal user, but many internal changes and improvements for administrators.
Changes in 1.8.0 Release
Among the key enhancements include an improved means of the merge tracking and identification of conflicts in the source tree to simplify maintenance of the projects. The new release introduces new features for automation of mergers on the client side and the identification of conflicts in the process of merging branches and code updates. In addition, the Subversion client is now considering tracking of working copies of items as the primary operations.
For administrators, Apache presented a unified mechanism for the Subversion configuration management on the client side, including the spread ignore patterns and automatically determine the properties. This mechanism is implemented by embedding inherent properties related to the configuration, directly to the repository.
ASF adds the possibilities with the backend storage implementation FSFS, which adds support for caching properties audits, packaging properties of revisions to the file and ensure the preservation for the properties and contents of directories. One of the areas where robustness has been improved is in the storage of metadata. SVN now tracks the moves of working copy items.
Additionally, version 1.8.0 is carried out avoiding the use of HTTP-library Neon. Now, client accessing the repository via HTTP is enabled by a new library called Serf. Serf is a high-performance HTTP client library which has formed the basis of an alternative HTTP repository access method for many years.
Moreover, Storage based on BerkeleyDB is deprecated and will no longer develop. The support for BerkeleyDB is retained, but other than bug fixes the implementation of innovations are now discontinued.
The other difference is that the personal repository has a section that specifies that access is denied to all, and admitted for an IP or domain name. This guarantees that the person accessing your repository is doing from an IP of your confidence, slightly increasing the security.
Other new features in Subversion 1.8 include in-memory caching of passwords, the server-side fsfs-stats statistics command, and the introduction of the svn-bench benchmarking client.
Source code for Subversion 1.8 can be downloaded from the project’s download page and unofficial binary packages are also available. A complete list of changes, for the client and the server, can be found in the official changelog.
Highlights of Apache Subversion 1.8.0:
Git vs. SVN
For some development projects/communities, where everyone is independent and rarely connected to a central point, distributed version control system make more sense. In recent years, the Git version control system has gained in popularity.
Most startups and research groups have been using Git from day one. Git makes common tasks such as merging, reverting, reviewing other people’s work and branching so much easier and intuitive than Subversions. According to a study by Ohloh, open source projects that use Subversion is average around 53%, compared to the 29% that use Git.
The downside for Git is that it only knows about files, and it makes guesses about where a file may have moved to, it doesn’t really track directory structure. With the SVN 1.8 release, Apache allows different people to work on different directories individually. SVN has fine grained permissions, access and authentication controls, which are very useful as parts of your project.
The use of FSFS also gives SVN an advantage over Git. With Subversion, you can have a 1T repository and check out just a small portion of it, the developers don’t need full copies. Git shops typically have many, smaller repositories, while svn shops typically have a single repository, which eases administration, backup, etc.
THANK YOU