Intro to Subversion Access Control 4.1

Big plans are brewing at WANdisco for 2012, and one project that has just been completed, is Subversion Access Control 4.1.

Access Control 4.1 includes a revamped user interface. The new look makes it easier for users to navigate through the security features offered by Access Control and setup new rules and permissions for Subversion repositories and paths.

The ‘Group’ concept has been replaced with “Teams’ and a new feature has been added to allow the designation of “Team Leader” who is then granted some administrator privileges. Specifically, the Team Leader is able to setup user access rules to a pre-defined repository path (or paths).

We are calling this new feature Delegated Admin since it allows granting of some administrator privileges to users. The context of how this feature could be used might be best described in terms of business units for an enterprise corporation. Consider the following scenario.

A company has 100 Apache Subversion users split into 10 teams, each associated with a separate BU, each team has its own Subversion repository. In the past, Access Control admin can go in and setup repository security rules that applies to all 100 users and repositories. With delegated admin the Access Control administration can create 10 new Teams and assign a Team Leader to each one, specifying the Repository that team should have access to. From there, the Team Leader can log into the system, add/remove the users for the team, and setup multiple rules needed to properly manage those Subversion assets.

Effectively what delegated admin does is allow Team Leaders, people in charge of their respective Business Units, to define and configure their own team rules. Access Control supports the concept of nested-teams which is called Sub-Teams (see screenshot) and this would even allow you to further organize teams from larger sections into multiple sub-sections (eg: West Coast Branch –> Plugins Team; West Coast Branch –> Application Team) and designate a team leader at each level to manage users and rules.

The role of the Access Control administrator now is to simply define Team Leaders and the resources which they can direct access over. Once defined the Team Leader can only create rules that affect their resources meaning the West Coast Branch won’t be able to setup access rules for the East Coast Branch’s repositories and vice-versa.

The ability to delegate some administrator functionality to Team Leaders, and in the context of specific Subversion paths and repositories, is a powerful new feature that will empower enterprise organizations and save time and money. Team Leaders are able to set access restrictions based on the need and requirements of their given team or business unit and no longer have to rely on a single administrator to do that for them.

Making Subversion Agile in a Distributed Environment.

Agile development is iterative and incremental. It requires continuous build-test-deploy cycles and continuous communication. Your SCM, whether it’s Subversion or any other, is the key enabler for communication about the most important aspect of any software development project: the current state of your code.

The biggest challenge to effective agile development in a distributed environment lies in maintaining the same level of communication, the same level of continuous integration and the same level of Subversion repository access that’s possible when everyone works from a single location. While you can partially overcome the effects of distance by putting certain practices into place, the implementation architecture and tools you choose can either help or hurt your efforts to be agile.

Central Subversion server and proxy server solutions like svnsync often can’t address requirements for high levels of communication and continuous build integration in large distributed organizations because:

• Network latency causes remote developers to check out source code and commit changes infrequently. Merge conflicts and other problems aren’t uncovered until later in the development cycle, resulting in broken builds, extra QA and rework.

• The latest changes aren’t available from remote sites, making continuous build integration impossible.

• Proxy server solutions such as svnsync have the same network latency issues for write transactions that central server implementations have. In addition, if the replication of a write transaction from the master to a read-only slave fails, with svnsync there’s no built-in capability for catching the error and retrying the failed transaction.

• If an IT organization wants the flexibility to allow all of its sites to run builds in parallel so that remote developers aren't dependent on a central build team's schedule and time zone differences, this won't be practical with a proxy server solution if build scripts include write steps that can only take place on the master server.

• Agile development requires a high level of availability. Central server and proxy server implementations have a single point of failure inherent in their architectures. This limits availability when the central or master server crashes, the network connection is lost, or the server has to be taken offline for maintenance

• If development takes place at only one location, with a large enough team, the combination of development activity and continuous build cycles on a central Subversion server can turn it into a performance bottleneck as well as a single point of failure, slowing down both developers and the build team.

In contrast to central server or proxy server solutions, with Subversion MultiSite’s peer-to-peer architecture there is no single point of failure, or performance bottleneck. Distributed Subversion servers are fully readable and writable at LAN-speed at every location and kept continuously in sync by WANdisco’s unique active-active replication capability. Each site can perform builds and test locally with the latest source code, regardless of where it originates. In a distributed environment, this provides the support necessary for continuous build integration that detects problems early and keeps software development projects from going over-budget. Delays caused by broken builds and scheduling conflicts with a centralized build team go away.

In addition, because WANdisco’s replication technology turns distributed Subversion repositories into mirrors of each other, continuous hot backup is achieved by default. Subversion MultiSite leverages this with automated recovery features that allow one site to recover from any other after a network outage or server crash. These capabilities can also be used to take servers offline for routine maintenance without interrupting user access, making 24-by-7 operation possible. As a result, Subversion MulitiSite delivers a higher level of availability in a globally distributed environment than a central server can with everyone at the same location. Downtime is eliminated and business continuity is insured.

Subversion Clustering is built on the same replication technology as Subversion MultiSite and delivers the same automated recovery capabilities that enable full 24-by-7 operation, with immediate and transparent failover. It allows Subversion to be deployed in an active-active cluster over a LAN and removes the single point of failure and performance bottleneck of a central Subversion server. It provides truly shared nothing clustering. There is no sharing of disk, CPU or memory between servers in a cluster. Intelligent load balancing capabilities optimize performance even further by taking each server’s current load into account before routing requests, rather than relying on simplistic round-robin approaches. Subversion Clustering is often used to improve Subversion’s performance by spreading the load created by continuous builds across a cluster of servers at large sites.

Subversion Clustering can be implemented standalone, or in combination with Subversion MultiSite to combine local clusters into an active-active WAN cluster that can be monitored and administered from one location. Remote users are routed to the closest site where Subversion servers are available.

Distributed software development reduces labor costs and provides access to wider talent pools and global markets. Agile development delivers cost-savings by catching problems before unplanned rework and QA leads to missed deadlines, and being flexible enough to allow software to change as fast as user requirements. In order to achieve this, the right processes have to be combined with the right technology to overcome the impact of distance on communication between developers. The bottom line is that when agile development is implemented successfully in a distributed environment, the greatest cost-savings and productivity improvements possible can result.

Keeping Multiple Subversion Repositories in Sync

With Subversion 1.4, svnsync was introduced for this purpose. The key problem with using svnsync for multiple Subversion repositories distributed over the WAN is its reliance on a master-slave architecture. While svnsync does provide the advantage of having local read-only repositories at each of the remote development sites, only the master repository is writeable. The master repository is then replicated to the read only slaves. However, the replication process can place a significant load on the network and servers. Because of this, replication tends to happen on an infrequent basis, leaving the read-only slave repositories that remote sites do their checkouts from out of sync with the master much of the time. As a result, commit failures due to update conflicts on the master repository can become a problem. In order to avoid commit failures, developers at the slave repository sites have to do updates over the WAN against the master Subversion repository before doing their commits. This can negate most of the expected network performance and developer productivity benefits of using svnsync in a distributed development environment.

Other solutions such as svk do allow multiple repositories to be readable as well as writeable, but there are no guarantees of consistency across the repositories. A commit can succeed on a developer’s local repository where there are no conflicts, and fail when it’s copied to other sites’ repositories due to update conflicts. This can make administration extremely difficult.

WANdisco solves these problems by turning distributed Subversion repositories into peers. All of the repositories are writeable, and consistency across the repositories is guaranteed. WANdisco’s active-active replication capabilities allow developers to work at LAN speed over the WAN for both read and write operations, while keeping all of the repositories in sync, in effect in real-time. WANdisco also provides self-healing capabilities that automate disaster recovery after a network outage or server failure.