Axure RP and Source Control with Subversion

If anyone out there is using or has thought about using Axure RP Pro for a project and stumbled at the source control hurdle, or decided against it for lack of source control support, I challenge you to read this post and still disagree. Axure RP is a great application that when used well can create great prototypes to ‘wow’ the client and then with a single click  generate annotated specifications.

The common question I hear is what about source control and scalability to more than a single person team?   For a project I worked on last year I had to come up with a process for managing Axure content with a 5 person BA team and retain and backup all version history. A quick google and flick through the help didnt prove all that useful so I dove in and have compiled a few steps from what I learnt.

Creating / Configuring the Subversion (SVN) Server

First step is to configure (or create if your organisation does not already have a managed SVN service) your source control server, which for ease of use I generally use Visual SVN Server and keep it on a stable server that isn’t handling much load already. Install Visual SVN Server from and configure as per normal.

Only option to change from default is to use integrated windows authentication – this saves you have from having to manage users, but if security is an issue, then it may be desirable to have user management within SVN.

Creating the Repository

Once Visual SVN is installed you should be presented with the Visual SVN Server Management Interface, as shown below.

The screen above already has a a repository created but let’s run through the process of setting one up.

From the ‘Repositories’ menu, right click and select ‘Create New Repository’.

Enter in the desired name ensuring not to include any spaces. I generally go for the ‘underscore’ format, e.g. Example_Axure_Proj_03

Once created there should a new repository in the overview window and on the left hand pane, as below. This will be the repository for all Axure content.

Right click on the newly created repository and select ‘Copy URL to clipboard’ as show below.

Now we have our repository setup and we have the URL to it, we can jump into Axure and create a new Shared Project!

Creating a Shared Project in Axure

Creating a shared project in Axure is reasonably easy process, much like that of creating a standard new project with an additional step.

From the Axure file menu, select ‘File -> New Shared project’

The ‘new shared project’ wizard will open and ask for a shared project name. This can be anything and is only used locally.

The next wizard screen asks for the location of the ‘Shared Directory’ so paste in the URL from the above step (if it does not come through, go back and repeat the step to copy the URL to the clipboard). Note: You can use a normal shared directory location for this, but using a SVN is more secure and gives you more control, particularly if you already have a managed SVN Server!

Axure will the confirm the repository is ok and everything is in order and then prompt the user for a local working directory, choose whatever you like for this. It will also prompt for credentials and depending on whether you used integrated authentication in your SVN setup or not, enter the relevant credentials.

Checking in / out and version history

Now that versioning is enabled and you are working from a ‘shared project’ the source control concepts of checking in / out now apply. Now items can be edited until they are first checked out the user and now item can be checked out to more than one user. These concepts should be very famailair to anyone who has used a source control or document management system before.

When checking back in items the a summary prompt will be displayed indicating all items that are being checked back into the source control and subsequently visible to all other authors.

All done!

Well that covers the basics of source control with Subversion (SVN) and Axure RP and with this combination you will be able to scale out Axure projects to multiple authors working of the same source and lock down editing permissions.

One other thing I usually do is write a simple batch file to do a daily backup of the repository store on the C:\ drive to a network share or document management system to give more redundancy and peace of mind. This way you can always create a new repository with data from a particular day and recover data from any day within the project lifecycle.