|
First you set up Subversion, then you use it
July 30, 2007
URL:http://www.drdobbs.com/open-source/subversion-and-linux-setup-and-use-part/201200496
Ramanathan Muthaiah is Configuration Management Lead at Infineon Technologies India. Ramanathan has more than 10 years of experience in customer support, network and systems administration, and configuration management, and can be reached at [email protected].
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:
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.
Subversion repositories can be hosted using either FSFS or Berkeley DB. The following sections provide an overview of the two file systems.
Berkeley DB. From the Subversion design book:
When the initial design phase of Subversion was in progress, the developers decided to use Berkeley DB for a variety of reasons, including its open-source license, transaction support, reliability, performance, API simplicity, thread-safety, customer support and so on. ... But every rose has its thorn, and so we must note some known limitations of Berkeley DB. First, Berkeley DB environments are not portable. You cannot simply copy a Subversion repository that was created on a Unix system onto a Windows system and expect it to work. Secondly, Subversion uses Berkeley DB in a way that will not operate on Windows 95/98 systems -- if you need to house a repository on a Windows machine, stick with Windows 2000 or Windows XP. ... Finally, because Berkeley DB is directly linked into Subversion, it's more sensitive to interruptions than a typical relational database system.
FSFS. 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:
Note: 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:
Briefly, I shall cover the:
In the second part of this article, I shall cover the following topics:
This topic is definitely one of the most commonly overlooked by those who venture to set up the repositories. For repository access via Apache's httpd, it is advisable for security reasons to create a special user or group (in lieu of a superuser (root)) and run "httpd" processes as this special user/group. This setup can be used in environments where access to the production repositories via http may be desirable. Additionally, users, who are required to access this storage using the http scheme, can be added to such special group(s) as well.
A sample user and group organization that enables playing with Subversion is shown below:
svnplaygrp:x:503:apached,svnroot,ram
From the Download pages of Subversion project, you can download the sources/binary packages of Subversion for various Linux distributions and also the dependency packages.
The command output shown in the following sections was extracted from an environment where Subversion v1.4.3 has been installed from the sources in a path different from the default one (/usr/local). As with many of the distributions, Subversion is bundled as part of the default installation packages, so you don't have to choose during the installation of your Linux distro. However, it is perfectly okay to have multiple versions of Subversion installed on the same system, as shown below.
sh-3.1$ svn --version svn, version 1.3.0 (r17949) compiled Feb 12 2006, 04:42:41 Copyright (C) 2000-2005 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/).
The following RA modules are available:
sh-3.1$ /opt/svn-1.4.3/bin/svn --version svn, version 1.4.3 (r23084) compiled Jan 31 2007, 23:25:04 Copyright (C) 2000-2006 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
However, extra care should be taken not to mix up the commands. It is easy to get trapped in a situation where the commands fail to work with the local WC or the repository. A possible reason for this is that the local WC and the repository have been created using commands from a specific version of Subversion, but the command used is from a Subversion available in a different path. This condition is shown here:
sh-3.1$ svn info /home/ram/svnarticle_draft/svn_article svn: This client is too old to work with working copy '/home/ram/svnarticle_draft'; please get a newer Subversion client sh-3.1$ /opt/svn-1.4.3/bin/svn info /home/ram/svnarticle_draft/svn_article Path: /home/ram/svnarticle_draft/svn_article Name: svn_article URL: file:///opt/samagdocs/trunk/svn_article Repository Root: file:///opt/samagdocs Repository UUID: d87b2b87-2545-461f-ae99-430b66f94c56 Revision: 35 Node Kind: file Schedule: normal Last Changed Author: ram Last Changed Rev: 35 Last Changed Date: 2007-01-13 17:27:01 +0530 (Sat, 13 Jan 2007) Text Last Updated: 2007-01-13 17:08:08 +0530 (Sat, 13 Jan 2007) Checksum: c68730a0fc6f5e9cdcecfebfb6fbde50
While installing Subversion from source, the correct path to "apr" and "apr-utils" must be provided; otherwise, it is possible that the repo access via "http" will not work properly even though Subversion was installed without errors. The "configure" script has options, --with-apr and --with-apr-util for this purpose. The inputs to both these options, preferably, should be the full path to "apr-config" and "apu-config" directories.
Of course, there are ways to check which libraries have been used as part of the installation and which are needed for proper functioning of Subversion. Some of these methods are given below:
mod_dav_svn should have utilized the same apr and apr-utils libraries as that of httpd. Both Subversion and http are linked to the same APR libraries, as shown:
sh-3.1$ ldd /opt/http-2.2.3/bin/httpd | grep -i apr
libaprutil-1.so.0 => /opt/http-2.2.3/lib/libaprutil-1.so.0 \
(0x00174000)
libapr-1.so.0 => /opt/http-2.2.3/lib/libapr-1.so.0 (0x00bd0000)
sh-3.1$ ldd /opt/http-2.2.3/modules/mod_dav_svn.so | grep -i apr
libaprutil-1.so.0 => /opt/http-2.2.3/lib/libaprutil-1.so.0 \
(0x00501000)
libapr-1.so.0 => /opt/http-2.2.3/lib/libapr-1.so.0 (0x00c6b000)
To specifically check which type of repository access mechanisms are available with your version of Subversion, run this command:
<path-to-Subversion>/bin/svn --version
The output may or may not look similar to the output sh-3.1$ svn --version shown above. By looking at the previous output, we see that the following access schemes are enabled:
There are no shortcuts or abbreviations (e.g., svnversion --ver) available for the different switches to go with the various Subversion subcommands. They must be typed/scripted as full whole words, for example: --version.
Probably the first thing to do, immediately after installing SVN, is to create a repository (a.k.a. repo). But, before setting up the repository, I also recommend these steps:
In our case, the repository is created in the file system of the local hard disk, as:
sh-3.1$ ls -ld /lnx_data/repos_holder/ drwxrwxr-x 2 svnroot svnplaygrp 4096 Feb 27 00:28 /lnx_data/repos_holder/
Next, do <path-to-Subversion>/svnadmin create <path-to-your-repos-dir>:
sh-3.1$ /opt/svn-1.4.3/bin/svnadmin create /lnx_data/repos_holder/testrepo sh-3.1$ ls /lnx_data/repos_holder/testrepo/ conf dav db format hooks locks README.txt
Organize the directory structure of the code the way you would like it to be in the repository. It helps to organize the structure before starting to import into the repository. Three top-level directories (branches, tags, and trunk) are needed. The actual data goes into "trunk"; whereas, the other two are empty.
The following example has the directory "testrepo" created in the home dir "/home/ram":
sh-3.1$ ls -l testrepo/ total 12 drwxrwxr-x 2 ram ram 4096 Feb 27 00:44 branches drwxrwxr-x 2 ram ram 4096 Feb 27 00:44 tags drwxrwxr-x 2 ram ram 4096 Feb 27 00:45 trunk sh-3.1$ ls -l testrepo/trunk/ total 0 -rw-rw-r-- 1 ram ram 0 Feb 27 00:45 bar.pm -rw-rw-r-- 1 ram ram 0 Feb 27 00:45 foo.pl -rw-rw-r-- 1 ram ram 0 Feb 27 00:45 Makefile
At this point, we can import data from the local dir "testrepo" to the actual repository. With the current directory being my home dir, we run the svn import command to finish this task:
sh-3.1$ /opt/svn-1.4.3/bin/svn import testrepo/ \ file:///lnx_data/repos_holder/testrepo/ -m "initial import into \ the scratch pad repo" Adding testrepo/trunk Adding testrepo/trunk/bar.pm Adding testrepo/trunk/Makefile Adding testrepo/trunk/foo.pl Adding testrepo/branches Adding testrepo/tags Committed revision 1.
Getting the most out of Subversion means doing those oft-repeated tasks with ease. Here, we shall quickly cover the basic commands and related switches that are most needed for novice users to get started with SVN.
To update the newly created repository, can be updated further, a local WC (an exact replica of the repository in its current form) should first be created. The command to create a local copy of the repo and its output is shown below.
NOTE: The last argument (testrepo_copy) to svn co is optional; if no argument is given, then the name of the repository is given to the directory that will hold the working copy. It is in the WC directory that the repository contents will be dumped:
sh-3.1$ /opt/svn-1.4.3/bin/svn co \ file:///lnx_data/repos_holder/testrepo/trunk testrepo_wcopy A testrepo_wcopy/bar.pm A testrepo_wcopy/Makefile A testrepo_wcopy/foo.pl Checked out revision 1.
Previously, I showed how to populate an empty repository using svn import. Subversion assumes that, prior to import, the directory hierarchy is well organized in terms of "branches, trunks, and tags" directories. So, how do we add new files or directories after the repository is created? For this situation, the command svn add is very helpful.
Create the new files and directories in the working copy directory and then execute svn add followed by svn commit:
sh-3.1$ /opt/svn-1.4.3/bin/svn add README A README sh-3.1$ /opt/svn-1.4.3/bin/svn commit . -m "new file to the repo" Adding README Transmitting file data . Committed revision 2.
This command comes in handy when the initial data to be imported is quite large, and doing the same via svn add would prove to be roundabout way to achieve the same objective.
With the svn add command, new files/dirs are added to the WC only but not to the repo yet. This task is accomplished with the command svn commit. New files are committed in the repo, and, upon successful commit, a revision number is shown. This number indicates how many revisions the repository has undergone including the current commit.
At significant milestones, the repository can be archived using tags (or "identifiers"). In Subversion, tags are nothing but folders that are created with names provided by the user; tags are created using the command "svn copy".
In the course of writing this article, I wanted to record the progress (at random intervals) of the manuscript; hence, I labeled the changes to it using the svn copy command as shown below (here "svnarticle_draft" is the working copy and "/opt/samagdocs" is the repo location):
sh-3.1$ pwd /home/ram/svnarticle_draft sh-3.1$ /opt/svn-1.4.3/bin/svn copy -m "sample tag" . \ file:///opt/samagdocs/tags/MANU_01REVIEW_27FEB Committed revision 37.
Subversion creates an exact replica of contents from the WC to the mentioned folder "MANU_01REVIEW_27FEB" under the "tags" directory of the repo "/opt/samagdocs". To confirm what constitutes this folder, we use the command, svnlook tree, like this:
svnlook tree /filesystem/path/to/repos | grep -A NUM-LINES \ "tag-folder-name"
This command, svnlook, does not accept a URL to the repo, but the file system path to the repo and the trimmed output of this command is shown below:
sh-3.1$ /opt/svn-1.4.3/bin/svnlook tree /opt/samagdocs/ | grep -A \
05 "MANU_01REVIEW_27FEB"
MANU_01REVIEW_27FEB/
images/
svn_move.png
svnignore_cmd.png
orig_populate_repo.png
svnserve_multiplerepos.png
svnserve_configuration.png
Subversion, like other version control tools, facilitates working in isolation via branches. Similar to tags, branches can also be created using the command svn copy. Branch creation can be done in two ways, but I will show the simpler and easier method here, which involves complete server-side action without involving the local WC.
The following is the output of svn copy used to create the test branch and then followed by svn look to highlight that the branch creation process is done successfully:
sh-3.1$ /opt/svn-1.4.3/bin/svn copy \ file:///lnx_data/repos_holder/testrepo/trunk \ file:///lnx_data/repos_holder/testrepo/branches/test_branch \ -m "simulating branch creation" Committed revision 4. sh-3.1$ /opt/svn-1.4.3/bin/svnlook tree \ /lnx_data/repos_holder/testrepo/ | grep -A 05 test test_branch/ bar.pm Makefile README foo.pl
Now that a new branch (copy of the latest from the trunk) has been created, you can check out from this namespace, then work from the checked out copy and merge with the trunk as needed.
Branch creation does not grow the repository size; only the changed files are maintained under the newly created "branch-dir", and the rest of the files (untouched/not modified) are referred from the existing tree. This is often referred to as Cheap Copies.
That's it for now. In the second part of this article, 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.
Thanks to the core Subversion team for providing a superb version control tool and the thriving dev and users mailing lists of Subversion, which continue to be a source of gyan (wisdom) for many, including me, because of the immense contribution from the active participants.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.