http://www.ddj.com/linux-open-source/201200496
July 30, 2007
Ramanathan Muthaiah
The Subversion open source project has come a long way and achieved major milestones with many significant releases. To get an idea of the growth of Subversion as a mainstream version-control system, have a look at the testimonials and security space survey at subversion.tigris.org . Given the steady growth and adoption of Subversion by major players in the FLOSS world, it is imperative to understand the working nuances of this open source tool.
In the first installment of this two-part article, I provide an overview of Subversion design blocks and, to possible extent, addressed the details in setting up the basic system and using the same via the "file://" access scheme. In Part 2, I look at additional subcommands (e.g., svn propedit, svn merge, and others). Access to Subversion repositories via svnserve and http schemes as well as the availability of various third-party tools for Subversion will also be addressed in the second part.
The Concurrent Versioning System (CVS) uses RCS storage for its repository needs and can track changes or revisions to file contents but not directory trees. It does not have provisions (out of the box) to copy, move, or rename artifacts stored in the repository without losing their history. Also, the inefficient handling of repository transactions over the network and branching/tagging operations are some of the factors that influenced the Subversion project team to go about writing a replacement for CVS.
Subversion is released under an Apache/BSD-style open source license. Here are some of the major highlights in Subversion:
- Atomic commits: With every commit to the repository, revisions and changes are committed either in full or none.
- Directory and metadata versioning made possible with virtual versioned file system.
- Advanced network layer: Subversion network server is Apache httpd and uses WebDAV as its network protocol.
- Faster network access: Regardless of file type, a binary diff'ing algorithm is used to store and transmit deltas in both directions (i.e., from/to the repository and Working Copy (WC)).
The Tigris Web site provides the set of features in Subversion v1.4 series; at this writing, the latest release (stable) was v1.4.3.
Briefly, I will cover the design of Subversion touching on its various layers. This layered architecture design (see Figure 1) is a significant improvement compared to the state-of-affairs in CVS.
Figure 1: Subversion architecture. (Courtesy www.svnbook.red-bean.com)
Subversion repositories can be hosted using either FSFS or Berkeley DB. The following sections provide an overview of the two file systems.
FSFS, another repository storage system, was introduced in mid-2004; it is a custom Unix-like file system but is not attached to the OS kernel like the ext2 and ext3 file systems. It doesn't use any database at all for its storage needs. The advantages of using an FSFS-type repository over the Berkeley DB are, portability across different operating systems, accessibility via networked file system, and less sensitive to crashes.
Apart from maintaining the revisions to file and directory contents, Subversion also keeps track of revisions to meta-data, known as "properties" (here again, user-defined metadata is not versioned).
Sandwiched between the "Client Layer" and the "File System Layer", the repository access (RA) layer is responsible for handling requests from clients to access repositories via HTTP, SVN, or local. RA is implemented as an abstract API by both the DAV and local access RA libraries. With this modular design and library-based implementation, it is easier for third parties to develop GUI clients.
This article would be incomplete if I did not mention the use of Apache in Subversion. Here are some reasons why Apache was chosen:
- Proven and stable
- Open source
- Platform support
- Proxy and firewall support
- Authentication mechanisms
![[Note]](../../../../asciidoc/images/icons/note.png){kind=icon} | |
The marriage of Subversion with Apache enables access to the repository from anywhere outside the office network without the need for a fat/thin client but via a simple browser, like Mozilla FireFox, Konqueror, or other browser that you wish to use. |
This layer provides most of the functionalities that are requested by users for all their work involving access to the various repositories. This set of libraries, together known as "Client Libraries", have provisions for the management of the WC, in terms of its administration, techniques, and methods (via API) of interacting with the repository and general client functions for those tasks that involve both the repository and the WC. For a detailed description of the libraries, refer to the Subversion site [4].
In upcoming sections, I shall step through the nitty-gritty of installation, configuration, and setup of Subversion using repositories based on the FSFS storage format. For the purpose of this article, the coverage is limited to these operating environments:
- Fedora Core 5 running Kernel 2.16.15-2054_FC5
- Subversion 1.4.3
- Apache Httpd v2.2.3
Briefly, I shall cover the:
- Setup of users and groups for repository access using either "file:" or "svn:" or "http" schemes
- Customized installation of Subversion
- Creation and setup of repository
- Overview of basic tasks in Subversion
In the second part of this article, I shall cover the following topics: http://www.ddj.com/linux-open-source/201200496?pgno=2
- Configuration of Subversion for svnserve and http access schemes
- Working with properties in Subversion
- General config files (in Subversion) and their needs
- Third-party tools available for Subversion
Copyright (c) 2007 CMP Technology
documented on: 2007-09-21
