Revision Management Solutions at Code-Host.net

Insurrection Web Tools

One of my pet projects has been to build a better web based interface to a revision control system known as Subversion.  The Insurrection project is the result of that effort.  While it is still under development, it already is a very compelling web interface to Subversion and is in active use in a number of places.

The project page is at http://insurrection.tigris.org/ but the source code can be accessed via the Insurrection tools itself at http://svn.code-host.net/.  If you use Subversion, you can get the latest code via: svn co http://svn.code-host.net/svn/Insurrection/trunk

Features

  • Easily browse the repository
  • Access any version of any file
  • View revision histories
  • View differences at various revisions
  • Annotate files with respect to author and revision
  • Get RSS and Atom feeds of changes in a repository or part of a repository or a specific file
  • All repository features are via repository consistent URLs
  • Administrate user access to repositories

Design Goals

  • Must work without the need to install anything on the host OS.  This means that all of the functionality of this system must work in a user process with a locally built Apache and Subversion code base.  We do assume some basic features of a "unix" like operating environment, such as having a basic Perl installation.
  • Make use of modern browser technology to reduce server side overhead and bandwidth usage.  This means using client-side XSLT transforms to embellish XML output into a presentable form.  This means heavy use of XSLT, CSS, and JavaScript where needed to product a better result.  No aiming at the lowest possible version.
  • Try not to use any browser or platform specific extensions if at all possible.  This means that none of the JavaScript will do browser detection.  There is one case were we have to check for a Microsoft-ism due to the lack of a common standard but the check is written such that if IE does start supporting the standard it will automatically used that form.  The minimum browser support is for Firefox 1.0, Mozilla 1.7.x, and IE 6 with IE 5+, Opera, and Safari to be supported where reasonable.  Safari is partially working due to bugs in Safari.  Opera is not working due to lack of an XSLT implementation.  (See these browser functionality tests that I have put together for details on client side requirements.)
  • To provide a way to administrate and support multiple repositories on the same server.  Currently the code does not support a single repository only format since it assumes a multi-repository structure.  Support for single repository configuration will be looked at if it does not adversely impact the support for multiple repositories.
  • To make sure that we don't use any more bad puns as we have used our allowance in the naming of this project.
  • ...more to come...

Project Status

The current code is in active use on a number non-public Subversion servers.  This does not mean that the project is complete but it is relatively stable.  Many things have not been cleaned up or as fully supported as I would like.  There is also a lack of clean documentation as to how to install the code.  This is because, so far, it has always been installed by the same person who wrote it.

I have put up a production server at http://svn.code-host.net/ that has the Insurrection code on it so you can see it in action.  I have also made some "Browser Shots" that show a small bit of what using Insurrection is like.  (Click to view screen shots)

I have put together some simple tests of the client-side/browser capabilities that the Insurrection system needs.  You can try these tests at http://svn.code-host.net/browser-tests/ and the source for these tests are in the source repository.

The goal of this set of tools is to become a reasonably complete Subversion repository browsing system plus a simple administration system for repository access controls.

Why reinvent the wheel?

While, in some ways I believe that I have built something that already exists, I have done so mainly due to direct needs or issues with what already exists.  See some of the design goals above...

The main reason was the need for running within a standard Linux server install without the need for any root access.  This makes this a clean install onto already supported NOC servers within a company without special needs or configuration.  The current setups I have installed allows for the migration of the whole system to another machine by just moving the user account and directories.  No special backup procedures, system installs, or extra patching for securty or administration.  (For example, my setup runs on a plain-vanilla RedHat AS2.1 install)

One of the key components that made this possible is the Subversion Filesystem database backend support.  In my testing of the FSFS repositories, I have found that they are actually more reliable than the BDB ones.  (Less operator intervention in the case of a lights-out environment.)