Using client certificate with Apache and Subversion

This is not a typical use case for anyone who use client certificate with Apache and Subversion. The use case is to use client certificate for all Apache requests, but not for Subversion requests. This sounds like a straightforward configuration in Apache configuration file, but it is not.

Usual workaround

The SSLVerifyClient optional directive is used to enforce client certificate based authentication. If it is specified at the <Location /> directive, all non-Subversion requests goes through client certificate based authentication. The SSLVerifyClient none directive is used to avoid using client certificate based authentication. If it is specified at the <Location /svn> directive, the Subversion requests does not go through this authentication.

413 -- Rquest Entity Too Large

If we use the above workaround, we face 413 HTTP error while uploading large files using POST method. It is due to bug 12355. According to this bug report, if SSLVerifyClient optional directive is specified at <Location /> directive, the user will face this issue. The bug report claims that it is fixed in Apache 2.0.55, but I faced this issue even in Apache 2.2.11.

The work around is to specify SSLVerifyClient optional at the virtual host level. But then, this setting can be overridden only using <Directory> directive. In our case, it can not be overridden using <Location /svn> directive. Thus the client certificate based authentication is enforced even for SVN requests.

SSLRenegBufferSize directive in Apache 2.2.12

The issue 413 Request Entity Too Large error is occurred when the SSL Renogtiation is attempted, because we specified SSLVerifyClient optional at <Location /> directive. The default size is 2048 bytes, which is not sufficient. In Apache 2.2.12, SSLRenegBufferSize directive is introduced precisely to configure the buffer size. I have not tried this in Apache 2.2.12 yet.

Snippet from Apache 2.2.12 changelog file.
The Hack to overcome this issue

We can not use SSLVerifyClient optional at virtual host level. We also can not let SVN requests go through client certificate based authentication.

We skipped the client based authentication for specific servlets which supports file upload, as far as Apache is concerned. We modified the code to still authenticate using client certificate only for these servlets. By using the following directive we fixed this issue. We also avoid specifying the SSLVerifyClient optional directive at <Location /> directive.

One of our customer reported a funny issue with the pre-lock.bat hook script. Yes, when he use Subversion Server on Windows system. The customer is using a custom pre-lock.bat script to explicitly lock the file before every commit. Why does he explicitly lock the file while svn commit itself locks the file implicitly? He has a valid reason to do so.

In earlier releases (>v1.6), Subversion discarded the stdout messages printed in hook scripts. It is applicable for all hook scripts including pre-lock.bat script. Starting v1.6, it behaves same with all hook scripts, except pre-lock.bat script. The message printed in this hook script is used as a UID for the lock. It should be unique across the repository. The best part about Subversion is, it is clearly documented in the Subversion 1.6 Release Notes.

Guess what? The customer complained that the custom pre-lock.bat script worked very well in prior releases, but it do not work with Subversion 1.6. When he commit the file, he face 423 Locked Error error. When we investigated if it is got to do with any stdout messages, NO. The hook script does not print any message to stdout.

WHERE DO THE PROBLEM EXISTS?

The issue is, the customer has set echo on globally in his Windows system. It prints all the commands we execute in the hook script to stdout, including the comments as in rem command. The solution is to set echo off in his system, and he no more faces the problem!

What is New in Subversion 1.5



As the saying goes Software never die until the last user die, every developer in a software project work towards improving the state of the software project. The team is engaged in adding new features, enhancing existing functionalities and fixing bugs. The Subversion project is not an exception. The Subversion development team is constantly working towards producing the good quality version control system, by defining standards for versioning methodologies.

In this article, we'll take a tour on various new features added in Subversion 1.5 release. It is not a complete list, but it gives an overview of important features the users have been waiting for so long. In this article, we cover few new features added in Subversion 1.5 release. It also provide a list of other features and improvements added in this release. However, we do not cover various bugs that are fixed in this release.

Merge Tracking

In pre 1.5 releases, merge is a utility outside of Subversion. The users are responsible to keep track of what to merge and record the merge information on the resulting revision. It is completely a manual process, the user should be intelligent to keep track of the merges. The following diagram illustrates the problem that exists in pre 1.5 releases.


In the above diagram, the user might face an error when he attempts to merge the revisions, revision 11 through revision 17, since revision 11 and revision 13 has been merged to the branch in the past.

This is one of use case addressed by the merge tracking feature in 1.5 release. It automatically handle the situations such a duplicate merges. It records the revisions that exists on a given path, and provides a traceability of what path made it to which revision. By automating the merging process, the information stored in repository is reliable. It is vital to certain industries with high demands on product safety.

It supports cherry picking changesets and it documents what changesets have been merged to where. It also records the merge done outside of the merge tool, probably using a manual process. The merge history is consistently recorded. The svn mergeinfo command answers various merge questions, what changes have been merged to any branch and what changes are eligible for merging from any source path.

Change Lists

At any given point in time, the developer may be working on multiple issues involving multiple source code files. The changelist feature gives the developer a flexibility to associate set of files with human readable changelist name. He can refer to these set of files using the changelist name.

For instance, the developer can create a changelist pointing to 10 source code files. Whenever he want to commit the changes in any of these files in the repository, he can use svn commit –changelist changelist_name command. This command will check if there are any changes in those 10 files and include the changed files for committing in the repository.  The user can manage changelists using svn changelist subcommand.

Sparse Checkouts

In Subversion 1.5 release, a facility is added to effect the operation for files and directories to a certain level. The --depth option is added to most for Subversion commands. This option is similar to --non-recursive (-N) and --recursive (-R) and improves upon these options making these options obsolete.

For example, the command svn checkout repos_url wc_path --depth files will checkout immediate target of the operation and all of its immediate file children. Similarly, the command svn checkout repos_url wc_path --depth immediates will checkout immediate target of the operation and all immediate files and directories. The directory children will themselves be empty.

Interactive Conflict Resolution

The conflicts may occur during following operations: merge, update and switch. In 1.5 release, an interactive conflict handling interface is provided for the user to fix the conflict instantly. The user can configure the default behavior during conflict resolution process.

The following table illustrates the list of options among which the user an choose while resolving the conflict:

$ svn merge proto://hostname/svn/branches/B1 .
Conflict discovered in 'B1/greek/iota'.
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : h
  (p)ostpone - mark the conflict to be resolved later
  (d)iff     - show all changes made to merged file
  (e)dit     - change merged file in an editor
  (r)esolved - accept merged version of file
  (m)ine     - accept my version of file
  (t)heirs   - accept repository's version of file
  (l)aunch   - use third-party tool to resolve conflict
  (h)elp     - show this list

  Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options :


FSFS Sharding

Before Subversion 1.5 release, the FSFS repositories contain files that describe the changes made in a single revision, and files that contain revision properties associated with a single revision. These files are kept in two directories, one for each type. As new revisions are committed to the repository, Subversion adds more files in these directories -- over time, the number of files can grow to quite large.

In Subversion 1.5 release, the FSFS backed repositories are created by slightly modified layout.  The content of these directories are sharded, or in other words, scattered across several subdirectories. This can greatly reduce the time it takes the system to locate any one of these files, and therefore increases the overall performance of Subversion when reading from the repository.

Other key features and improvements

In Subversion 1.5 release, few more features have been added. The functionality of existing features have been improved dramatically. The key features that are not covered in this article are as follows.

WebDAV transparent write-thru proxies
Cyrus SASL support for ra_svn and svnserve

The substantial improvements for existing features are as follows:
 
Copy/move improvements
Externals improvements
Cancellation improvements
Easier to try out ra_serf DAV access module
Lots of API improvements and miscellaneous bug fixes

Conclusion

So far, you have been using Subversion as a standard for Version control system. After Subversion 1.5 release, you would be surprised to see the comfortableness it provides for any developer while working on any software project. The Subversion version control system can be downloaded from following websites:

http://subversion.tigris.org
http://open.collab.net

About the Author

By: Bhuvaneswaran A. The author is currently employed in CollabNet working for their Operations Engineering group. He is an Official Member of Ubuntu Linux and a Partial Committer for Subversion project.

The article is published in Linux For You Magazine May 2008 Edition. The article in PDF format can be downloaded from here.

The GNOME project has been migrated from CVS to Subversion. It is a good news when count of Subversion users are already doubling every 5 months.

+

The Subversives. The three day event comes to an end. It was a wonderful event and today is the final day. Developers from many part or world including Canada, UK, India, Belgium, Russia participated in the event. It was meant for full/partial committers. We had couple of brain stroming sessions on following topics:

* svn obliterate
* svn merge tracking
* svn incomplete directories
* How to get world domination?
* Automated build bot
* svk
* Enchanced cross-platform functionality
* feature set for svn 2.0
* and many more...

We also had pgp key signing party.

I'm glad to be part of this community. In addition to Subversion specific topics, i came to know how a community evolves in long run. How they add new features? How they take the competition? How they face certain issues legally on international stage. I was able to meet many leading open source gurus including Brain Behlendrof, Karl Fogel, Brian Fitzpatrick, Ben-Collins Sussman, Greg Stein, Garett Rooney and many more in person. It's very useful to me and i look forward to contribute as much as i can. The summit was reasonably productive.