Subversion Edge 2.3.0 was released last week with a number of new features. One of those new features is that we are continuing to expose more and more of Subversion Edge via REST API. The documentation for the API is available in the Subversion Edge wiki.
Subversion itself has always had a very rich API for working with your repository data, but the actual configuration and management of a Subversion server resides outside the Subversion software itself. That is where Subversion Edge comes in to play. Subversion Edge is a packaging to the Apache httpd, Apache Subversion and ViewVC open-source products. All fully tested and designed to work together. Subversion Edge also includes a custom web console for configuring and managing your server. This console is what gives you the “Edge” when it comes to managing your server and it is also where the REST API lives. Using this API you can do things like get a list of all repositories, you can create a repository, you can work with the hook scripts for a repository, you can create users etc. Here are some examples for how the API can be useful.
CollabNet currently offers four distinct “Desktops” (Eclipse, Visual Studio, Windows and Outlook). These desktops deliver our custom clients for TeamForge, as well as Subversion, in a native desktop client. The latest version of the CollabNet Desktops have been enhanced to support Subversion Edge servers via the new REST API. Using the API, a user can just specify the URL of their Subversion Edge server, along with valid credentials, and the Desktop client can then use the REST API to retrieve a list of all of available repositories on that server. If you only have a single repository, this is not that big of a deal, but most of us work with many repositories. Now you do not have to enter all of those URL’s into your Subversion clients in order to browse and checkout code. In addition, when new repositories are created they will automatically show up in your list and be available immediately.
I was recently doing some testing of the Subversion Edge web UI to see how it worked with large amounts of data, such as thousands of users and repositories. I wanted to have data that looked real world so I did not want to name my repositories with names like repos-1234. Using some screen scraping, I connected to tigris.org and retrieved the names of all of the public projects hosted on that site. This served as a good set of real world data for my repository names. I then just had to write a simple script that read through this list of names and called the Subversion Edge REST API to create those repositories, and I did something similar to create my users. By using the REST API, I was able to easily change my script to target different servers running on different operating systems by just changing the URL in the API call. In a couple minutes I had thousands of repositories and users created on my server and could move on with my testing.
While, it is unlikely that you would want to create thousands of repositories and users the way I did, you still might have internal business systems that you want to integrate with Subversion. For example maybe you have an internal process you follow to request a new repository or to start a new project. When the request is approved, you could now enhance these internal processes to call the REST API to create the repository. Using the repository templates feature in Subversion Edge when creating your repository or the REST API for hook scripts after you create the repository, you can make sure the new repository has all of your corporate standard hooks in place as well.
Integrations are just a flavor of automation, but here is another real world example for how the REST API could be used. About a year or so ago I was having a brainstorming session with Kohsuke Kawaguchi of Hudson/Jenkins fame. We were talking about how we could improve the experience of using Jenkins and Subversion together. We already had one piece in place at that time, namely when we designed Subversion Edge we included a Discovery API so that it would be possible to automatically discover Subversion Edge on your LAN. Kohsuke had already been doing something similar with Jenkins, but he liked the way we approached it and wound up adding a similar implementation in Jenkins. So the Discovery API is step one (keep in mind this is all still “vision” at this point). What we imagined was that you already have Subversion setup and you are adding a Jenkins server on your LAN for Continuous Integration. Jenkins could have a plugin for Subversion Edge that auto-discovers your server and then calls an API to get a list of repositories. It could then use this information to assist you in setting up Jenkins build jobs for the projects in those repositories. Finally, because the Subversion Edge REST API also allows you to configure the hooks for a repository, this theoretical Jenkins plugin could also assist you in installing a post-commit hook to trigger your Jenkins builds. This is a more efficient way to trigger builds than polling the repository and also allows your builds to be started faster.
At this point, I do not know if a plugin like this will be created or not, but it should give an idea as to the possibilities that the Subversion Edge REST API now provides. As always, I invite you to come to our open discussion forums to ask questions and exchange ideas. Our goal is to have complete coverage for the entire Subversion Edge web UI available via API. We have been prioritizing around the areas where we think people are most likely to want an API. There is still a little more work to do to have complete coverage via API but we are probably more than two-thirds the way there and think we have likely covered all of the most common use-cases already. Feel free to request additional API or features if you have ideas that are not currently covered or in the plan.
Subversion Edge is FREE and Open-Source. Download it from CollabNet.