Subversion Edge 3.1.0 has been released today and is available immediately for download as well as via the integrated updates within the Subversion Edge web user interface. The primary new feature in this release is support for the newly released TeamForge 6.2, more on that in a minute. There are also fixes for all of the top bugs that have been reported in the forum. For a full account of what is included in this Subversion Edge release, please see the wiki page for this release.
For those of you on an older release of Subversion Edge, this would be a great time to upgrade. See my recent post on Ten Reasons to Upgrade your Subversion Server.
TeamForge 6.2 for Subversion Edge Users
As noted earlier, the primary new feature in this release is support for TeamForge 6.2, which has also been released today. TeamForge 6.2 brings a number of compelling new features for Subversion Edge users and once you have installed TeamForge on your Linux server, it is a very simple process to connect your existing Subversion Edge servers to TeamForge and gain all of these great features. When you connect a Subversion Edge server to TeamForge, the Subversion Edge server and repositories all stay in place, the management of the repositories and users simply moves into the TeamForge web UI. A single TeamForge server can manage any number of Subversion, CVS and Git servers and repositories.
Wildcards in Path-based Permissions
TeamForge already provided many nice upgrades to vanilla Subversion and Subversion Edge when it comes to permissions management. For starters, it is both project-based and role-based, so as a site administrator you can delegate the administration capabilities for a project to a project administrator. They can then manage the users, repositories and permissions within their project using the powerful role-based access control facilities within TeamForge. The great thing about this is that the project administrator has no explicit power outside their own project. They might be administrators for several projects, but just a regular users on others. They also may not even be able to see that other projects exist.
TeamForge’s role based access control is graphical and web-based. You do not have to edit rules in a text file, instead you define the access rules for the roles you create in your project and then simply assign users and groups to the roles which they belong.
TeamForge 6.2 builds upon this powerful feature with support for wildcards in path names. With vanilla Subversion, and earlier releases of TeamForge, if you have a folder named “secure” and you want to limit who is allowed to read this folder you need to define a rule to protect the folder. The problem is that if you copy your project to create branches and tags, then you also need to create a new rule for the new path name. Using the Subversion authz file syntax as an example, you need something like this:
[repos:/] * = rw [repos:/trunk/secure] * = @admins = rw [repos:/branches/branch1/secure] * = @admins = rw [repos:/tags/tag1/secure] * = @admins = rw
As you can see in this example, to fully protect the folder in all the locations where it exists, you are essentially forced to add a rule for every new location that is created in the repository. It is pretty easy to forget to add a rule after creating a new branch, and if you do, you risk exposing the folder that you wanted to protect. With TeamForge 6.2, you simply define your original rule using a wildcard path. In TeamForge this is done graphically, but the rule winds up looking like this:
[repos:/] * = rw [repos:/**/secure] * = @admins = rw
You can specify a value of /** to match any number of path components, or /* if you only want to match a single path component. With this feature, it is much simpler to define your access rules and know they are being applied correctly. In order to implement this feature we developed a new Apache auth module written in C that applies these rules. This replaces the previous TeamForge auth module that was written using Python. A side-benefit of the new module is that not only does it provide this new capability but it also is significantly faster. So all existing TeamForge users will see a performance benefit in their path-based permission over what they had in previous releases.
Integrated Code Search
Another new feature in TeamForge 6.2 is integrated code search. The integrated search feature in TeamForge has always been one of its most valuable features. However, when it came to source code, TeamForge only provided search of the metadata, such as the commit messages. TeamForge 6.2 includes a special tightly integrated version of Black Duck’s CodeSight which now expands the search feature of TeamForge to include the content of source code. When performing searches you can even do things like limit the search to a specific programming language.
Integrated Code Review
We have been using Review Board internally at CollabNet for a few years now. It is hands-down the best code review tool for Subversion with nice support for both pre and post commit workflows. With TeamForge 6.2 we have integrated Review Board into TeamForge using the CollabNet Connect framework. This makes Review Board another integrated tool that you can add to your projects and it allows your code reviews to be exposed as first-class TeamForge objects. This allows you to create associations to code reviews from other TeamForge objects like artifacts, code commits and wiki pages.
Over the last several releases of TeamForge there has been a new feature emerging and that is the presence of an open datamart for driving ALM reports. Each release of TeamForge has added new ALM information to this datamart and exposed more and more of it in the TeamForge UI. With TeamForge 6.2, you now have integrated reporting of SCM commit activity as well as Tracker artifact open/close activities. This is available at the site and project level to allow you to track the activity in your projects and repositories. In addition to the built-in reports, custom reports can be produced directly off the datamart.
A recent survey of Subversion users showed that roughly 28% of you are also using Git alongside Subversion. TeamForge 6.2 adds full support for Git for version control and Gerrit for code review. TeamForge makes Git ready for the Enterprise, and perhaps more importantly it allows you to work with both Git and Subversion from one ALM application that fully supports both. So you can have one team that uses Git for their project, another that uses Subversion and maybe a third that has a need to use both. All of them can be managed from the same integrated framework with full access to all of the tools that have been mentioned in this post as well as all of the others that are available in TeamForge.
I recommend Subversion Edge users download and install today’s update to Subversion Edge. Again, if you are looking for reasons to upgrade please take the time to read my Ten Reasons to Upgrade Your Subversion Server. Hopefully you find the additional information I have provided about TeamForge 6.2 interesting and relevant. TeamForge is available for download today and if you want to try all of the new TeamForge 6.2 features you only need a Red Hat or SuSE Linux server to install it. I recommend you install TeamForge on a separate server from Subversion Edge so if you are running Subversion Edge on Windows, you can still connect it to TeamForge running on a separate Linux server. They do not need to run on the same operating system.
* Apache, Apache Subversion and the Subversion logo are trademarks of the Apache Software Foundation. Subversion® is a registered trademark of the Apache Software Foundation.