After a long pause, here I come with another technical article.
Yes, Subversion’s long awaited release 1.7 has finally been set for it’s launch this 11th of October 2011. The following are a few notable pro’s about Subversion 1.7.
The new version, to be released shortly, promises the best Subversion experience to date. Subversion 1.7 delivers enhanced performance, new and improved features, important bug fixes, and a completely redesigned client-side storage layer which will serve as the basis for innovation in future releases.
A completely redesigned working copy library speeds common operations, streamlined communication between clients and servers, and much more
The Apache Subversion project expects to soon announce the general availability of the eighth major release of its ubiquitous open source version control system. Subversion 1.7.0 will be the first release from the project since its celebrated move into the Apache Software Foundation’s famous family of mission-critical software projects. Now, after baking for a couple of years, the oven timer is finally ringing. So just what’s being served here?
The single largest feature in the 1.7 release isn’t even really a feature in and of itself, but is instead a major plumbing overhaul. Subversion ships as a collection of well-defined libraries and APIs, with tooling (such as the “svn” command-line client) to make it all usable. The oldest of those libraries is the so-called working copy (WC) library, which is responsible for tracking enough client-side information about your version-controlled files so that Subversion can easily detect, examine, revert, and publish the changes you make to those files. As Subversion’s data model and feature set matured over the past decade, this library grew in a somewhat piecemeal fashion, eventually evolving into a messy chunk of code that was hard to maintain and even harder to cleanly enhance.
Subversion 1.7 delivers a completely redesigned working copy library, universally referred to as “WC-NG.” This work is the single defining feature of the release. As is often the case with such code overhauls, the new library implementation flies somewhat under the radar from the user’s perspective. But while the original intent was to deliver a new foundation for future improvement, Subversion’s developers — and by extension, its users — are already reaping a harvest of immediate, tangible benefits from this work.
The biggest benefit that WC-NG brings is enhanced performance. The original WC library distributed the working copy’s administrative metadata throughout the directory hierarchy. Because of this, most Subversion operations had to walk the entire directory tree — often, multiple times — just to gather the required information about, and apply changes to, the working copy. WC-NG instead centralizes all this information in a single database, so most of those slow directory walks have been completely eliminated. On operating systems with less-than-stellar filesystem performance (such as Microsoft Windows), the difference is notable, with some users reporting that their most common operations are faster by an order of magnitude!
Besides the improvements in speed, WC-NG has already allowed the Subversion developers to fix a large number of known defects. There are far too many to list here, but there is one that certainly deserves a mention due to its commonness: case-only renames. Prior to 1.7, Subversion failed when users on case-insensitive platforms (such as, again, Windows) tried to rename a file in such a way that the old name and new name differed only in the letter casing, e.g., from “myfile” to “MyFile.” This ancient bug is now fixed — and a slew of additional bugs along with it!
The benefits don’t stop with the core Subversion distribution. Providers of third-party Subversion clients and IDE integrations (AnkhSVN, Subclipse, TortoiseSVN, etc.) report that WC-NG’s capabilities are already enabling the addition of new features to those tools. It might have been a thankless plumbing overhaul, but it would appear that WC-NG’s new pipes terminate at a virtual Fountain of Youth for the Subversion project.
Revised HTTP Protocol
Another important-yet-mostly-invisible enhancement made in Subversion 1.7 is best described not so much by what the software now does, but by what it no longer tries to do. You see, Subversion was born back in a time when the Web-based Distributed Authoring and Versioning (WebDAV) protocol was relatively new. As new protocols tend to do, WebDAV — specifically, the Delta-V extension thereof — made big promises. The possibilities of a standards-driven version control protocol were mind-boggling: can you imagine using your Subversion client to communicate with a ClearCase VOB server? So Subversion set off into the exciting frontier of WebDAV/Delta-V, using the Apache HTTP Server and its reference implementation of WebDAV as the primary building blocks of the first Subversion server.
Unfortunately, Delta-V failed to catch on. Subversion’s client/server communication was, as a result, unnecessarily chatty and abstract. So the Subversion developers officially gave up on the dream of interconnectivity and decided to put its HTTP communication protocol on a strict diet. Subversion 1.7 delivers more streamlined communication between Subversion clients and servers while still preserving compatibility across all released Subversion versions to date. Subversion 1.7 also preserves the parts of its WebDAV/Delta-V implementation, which remain beneficial to users — such as the so-called “autoversioning” support, which allows Subversion repositories to be mounted as fully operational remote WebDAV filesystem shares.
It’s not over yet. Here you go with SVN 1.7 FAQ’s
Webinar : http://www.collab.net/webinar/110/
Source : http://drdobbs.com/open-source/231500282