Monthly Archive for August, 2012

WANdisco’s August Roundup

This month we announced some exciting releases for the Apache Subversion community: the release of Subversion 1.7.6, and updates for uberSVN and TortoiseSVN.

Building on the 1.7 series, Apache Subversion 1.7.6 added even more fixes and enhancements for the SVN community:

  •  A fix for running tests against httpd version 2.4
  • Constant struct initialisers now used for C89 compatibility
  • Fixes for the output of ‘svn propget -R’ ‘svn proplist’ and ‘svn status’
  • Optimized ‘svn upgrade’ performance on large working copies
  • A fix for ‘svn upgrade’ on working copies with certain tree conflicts
  • Fixes for two asserts into errors for TortoiseSVN

More information on what’s new in Subversion 1.7.6 can be found in the Changes file. As always, if you want to get your hands on the latest, certified binaries you can do so from our website. The latest version of TortoiseSVN – 1.7.8 – is also available for download. This release is linked against Subversion 1.7.6, and features a list of bug fixes. For more information on all the updates and fixes in TortoiseSVN 1.7.8, check out the Changelog.

The uberSVN community also saw an update, as the WANdisco developers finished off uberSVN ‘Chimney House’ Release 3.

uberSVN ‘Chimney House’ Release 3 features many improvements and enhanced functionality for uberSVN’s ever-growing community of users. These include:

  •  Further improvements to the way uberSVN handles LDAP and LDAPS.
  • Improvements to uberSVN APIs and internal development of the uberSVN SDK (public release coming soon!)
  • New manageAPPS page allows you to see metadata attached to your APP license, such as expiry date, number of named users, and more.
  • A list of bug fixes, including some fixes and alignment/mapping of the uberSVN Access Control Team Leader and uberSVN Delegated Team Admin (where uberSVN Access Control is active)
We also conducted a community poll to find out more about how you’re using Subversion. We asked what operating system your Subversion server is running on and, once again, there was a very clear winner…..

You may have already noticed that we’ve been adding new Subversion refcards. We’ve had such a great response that we’ve already put together two more – ‘All About the Apache Subversion Commit Command’ and ‘All About Checkouts.’ The first covers everything from the basic “what is a commit?” to more advanced information on editing log messages, ignoring files and directories, and an intro to hook scripts. ‘All About Checkouts’ provides a quick reference to making full use of the checkout command and understanding the messages generated under different scenarios.

We hope you’re enjoying these latest refcards, and if have any ideas for future refcards, please do not hesitate to Contact Us. If you’re after more Apache Subversion know-how, then why not take a look at our upcoming Subversion Live conference?

On the enterprise side of things, we published a new case study of our enterprise-class Subversion MultiSite product. The case study looks at how global logistics technology leader Navis – a subsidiary of Cargotec, enjoyed a 10x improvement in Subversion performance and achieved 24-by-7 uptime across all of their development sites after implementing our Subversion MultiSite solution. Read the Navis case study in full to find out more.

Also this month, WANdisco CEO and co-founder David Richards was asked to do an interview with BloombergTV – check out the full video interview below!

Finally our friend, photographer Matt Lollar popped into the office to take some new snaps of WANdisco’s Sheffield office.


Creating Your First Job in Jenkins with uberSVN

As uberSVN fans will already know, Jenkins has been available as a free, easy-to-install download through uberSVN since April 2011, and we have since extended our partnership with CloudBees to offer professional support for Jenkins.

uberSVN makes the popular Jenkins continuous integration server easy-to-install and easy-to-download, bringing benefits such as the automatic creation of software builds to Apache Subversion users. Getting started with Jenkins in uberSVN couldn’t be easier. Once you have Jenkins installed in uberSVN, your first task is to create a Jenkins job, and in this short tutorial, we’ll cover exactly this.

1) From uberSVN’s ‘repositories’ tab, select the repository you wish Jenkins to be associated with. In this example, we will use the ‘New Project’ repository.

2) Select the secondary ‘Jenkins’ tab. In the subsequent ‘Job Creation’ screen, enter a name for your job and a description, and click ‘Create.’

3) You will then be prompted to configure your job, by selecting available options for how you want your job to be set up (email notifications, publish JUnit test result reports, source code management, etc.) When you are happy with the configuration, click ‘Save.’

4) When you view your repository in uberSVN you will notice that a new ‘Jenkins’ tab has been added, which contains the job you have just created.

5) To start the job, click on the ‘New Jenkins Job’ link. On the subsequent page, select ‘Build Now’ to start Jenkins.

You have now successfully created your first Jenkins job in uberSVN.

Need more Subversion know-how? After getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012, bringing the Subversion community sessions covering everything from Subversion’s future, to expert-led best practices workshops, as well as the unique opportunity to meet the core Subversion committers..

New Case Study: Logistics Technology Leader Navis

We’ve just published a brand new case study on how Navis, a global logistics technology leader, has experienced a 10x improvement in Apache Subversion performance and achieved 24-by-7 uptime across all of their development sites.

Navis recently replaced the svnsync tool with Subversion MultiSite, our replication, mirroring and clustering solution, and have since reported:

  • 10x faster check in and checkout times.
  • 24-by-7 availability with no downtime – including maintenance periods.
  • All locations receiving immediate access to the latest version of the repository.
  • Dramatically improved collaboration between their globally distributed development teams.
  • Low administrative overhead as the entire implementation can be managed from a single location.

“Prior to implementing Subversion MultiSite, we experienced problems with downtime and our developer productivity,” said Steven Schleiger, IT Director, Navis. “Check-in and checkout times were particularly problematic at remote sites. Our previous solution also didn’t meet our requirements for continuous integration. We needed and found a fast reliable solution from WANdisco that provided 24-by-7 availability for all of our sites.”

Check out the case study in full for in-depth information on the challenges Navis faced with svnsync and how they implemented Subversion MultiSite in their organization.

Subversion Tip of the Week

Tagging and Reverting in TortoiseSVN

Apache Subversion remembers every change made to its files and directories, which gives you the option of reverting to earlier versions of your code (useful for when you need to roll back to a revision before it all went wrong!) Tagging is an essential part of this process, giving you the option of labelling a specific revision with a handy, human-readable tag. Here’s our five step guide to creating a tag, and then reverting to that tag, a few revisions down the development line.

1) Right click on your working copy and select the ‘Branch/Tag option from the TortoiseSVN’ menu.

2) In the subsequent dialog, perform the following actions:

– select the ‘tags’ path and add the desired tag (in this example we’ll use ‘Release_5.0”)
– add a log message.
– select the revision you wish to tag.

When you are finished, select ‘OK’ to create your tag.

3) To roll back to this revision at a later date, right-click on your working copy and select ‘Show Log.’ This will bring up a list of revisions.

4) Select the revision you wish to revert to and right-click. Select ‘Revert to this revision.’ When prompted, confirm you wish to revert, and TortoiseSVN will revert to this revision.

5) Check the results of the revert and, if you’re happy with them, commit your working copy back to the repository. Warning: this will discard all the changes you made after the selected revision.

Need more Subversion know-how? After getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012, bringing the Subversion community sessions covering everything from Subversion’s future, to expert-led best practices workshops, as well as the unique opportunity to meet the core Subversion committers.

Software is Everywhere – Let’s Make Sure it Works

I’ve just returned from a pretty interesting week in London mainly catching up with financial analysts, fund managers and the press (I’ve embedded the interview I did with BloombergTV a couple of hours after getting off the flight from SFO-LON).

At this stage (only a couple of months into our IPO on the London Stock Exchange) I find that I have to spend a lot of my time explaining what we do.  I suppose that shouldn’t be a big surprise.  Outside of ‘techie’ circles WANdisco is still a relative unknown, but I’m pleased to say that’s changing.

Most of the context for the “what we do” is explaining how software is developed in organizations and just how important it is.  In the techie bubble that we sometimes live we all take for granted.  Marc Andresson famously wrote about “software eating the world where he argues that “we are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the economy.”

Of course I think he’s right.  There are plenty of examples where software has replaced the incumbent.  My favorite example is the automobile industry where diagnostics used to be a guy under the hood and is now plugging the car into a computer and looking for trouble codes (there are 10 million lines of source code in a Chevy Volt).  Or, under the covers, how banks a really software companies employing thousands of software engineers.

It’s even easier to explain how important software is when it goes wrong.  The most recent example was at RBS / Nat West.

A software update was applied on 19 June 2012 to the software that controls the payment processing system. It then turned out that the update was corrupted.  Customer wages, payments and other transactions could not happen.  Millions of customers were unable to withdraw cash using ATMs or see bank account details. Others faced fines for late payment of bills because the system could not process direct debits. It wasn’t until mid July that the problem was finally rectified.

As one customer put it:

“I was due to have my wages paid in today – but they haven’t appeared in my account. This means I simply can’t afford to pay my weekly bills.

 “I also had to pay the deposit for my daughter’s headstone today – she was stillborn seven weeks ago. No wages therefore no headstone.

 “I am so angry about the technical glitch, as they call it, because this now means I’ve got to wait another week before having a day off work so I can go and pay for the headstone.”

The cost to RBS is unknown – but it could be billions.

At the heart of the problem was version control and release management of software.

According to current and former employees controls were not in place and it was difficult to know exactly what software was even running in the production system.  Release Management is supposed to be the ‘gatekeeper’ between the test & QA system and the production environment and clearly this was missing here.  In mission critical environments such as this there should be very strict controls in place.

Bugs exist in software, of course they do, human beings create software.  Companies employ systems such as software version control, source code reviews, QA, release management, staging, and integration testing to avoid this happening.  Modern software in today’s market should employ continuous integration testing.  This should ensure that every new line of software is changed it is tested across thousands and thousands of different test cases to see if anything is broken.  This reduces time to fix and also reduces even the chance an error will make it to QA.

Software is everywhere – it’s in your car, refrigerator and phone.  It’s not a nice to have – it’s a must have. Banks and other finance companies have been transformed by software over the last 30 years. Virtually all financial transactions, from someone buying a sandwich to a multi-billion pounds trading, is done in software.  That’s great but it presents risks – mission critical applications such as this can’t have bugs – full stop and process and modern tooling is not an option it’s a must.  Missile defense systems can’t have bugs; neither can medical devices such as heart pacemakers.  So you see it is possible to deliver software without bugs you just need good tools and processes.



About David Richards

David is CEO, President and co-founder of WANdisco and has quickly established WANdisco as one of the world’s most promising technology companies. Since co-founding the company in Silicon Valley in 2005, David has led WANdisco on a course for rapid international expansion, opening offices in the UK, Japan and China. David spearheaded the acquisition of Altostor, which accelerated the development of WANdisco’s first products for the Big Data market. The majority of WANdisco’s core technology is now produced out of the company’s flourishing software development base in David’s hometown of Sheffield, England and in Belfast, Northern Ireland. David has become recognised as a champion of British technology and entrepreneurship. In 2012, he led WANdisco to a hugely successful listing on London Stock Exchange (WAND:LSE), raising over £24m to drive business growth. With over 15 years' executive experience in the software industry, David sits on a number of advisory and executive boards of Silicon Valley start-up ventures. A passionate advocate of entrepreneurship, he has established many successful start-up companies in Enterprise Software and is recognised as an industry leader in Enterprise Application Integration and its standards. David is a frequent commentator on a range of business and technology issues, appearing regularly on Bloomberg and CNBC. Profiles of David have appeared in a range of leading publications including the Financial Times, The Daily Telegraph and the Daily Mail. Specialties:IPO's, Startups, Entrepreneurship, CEO, Visionary, Investor, ceo, board member, advisor, venture capital, offshore development, financing, M&A

Version Control In The Enterprise

Apache Subversion is gaining increasing popularity within the enterprise and, when you consider all the potential benefits, it’s easy to see why. Client requirements change, and new features can sometimes cause more problems than they fix. In these situations, Subversion effectively provides you with an undo button, allowing you to write some code, realise it doesn’t work, revert to a previous revision, write some more code that does work – and finally receive new client requirements and restore the original version of your project, ready to start again from scratch. Without Subversion, the above situation would have to be managed manually, but SVN provides all the functionality you need to make such situations as straightforward as possible.

Still on the fence about whether Subversion has a place in the enterprise? Here are our top three reasons, for keeping your enterprise projects under SVN’s version control:

  • Easy Collaboration – Subversion makes collaboration easier by allowing multiple developers to access the same code in a central repository, regardless of geographical location. This is invaluable in distributed, global organisations.
  • Keep Up to Date With Changes – Subversion keeps development teams synchronized with the latest changes in the central repository. Developers can pull all the latest changes into their working copy with a simple ‘svn update’ command.
  • Revert to Previous Revisions – Subversion’s version tracking functionality allows you to recover previous versions of your project without the hassle of manually unpicking your changes. This is useful if you have implemented changes that haven’t worked out, or turned out to be unnecessary. In some situations, it may even be quicker to revert to an earlier revision and then re-implement only the changes that worked, rather than trying to isolate and remove specific changes. Having an easy way to restore previous revisions when development teams hit difficulties, can also have a big impact on maintenance costs.
  • Improved Productivity – Ultimately, Subversion improves developer productivity. It allows multiple developers to work on the same project, at the same time, and imposes conventions that mean complications caused by accidental overwrites, lack of communication and manual merging, are less likely. Whenever defects are introduced, version control gives you the option of rolling back to a time before these defects found their way into your project.

Interested in seeing how Subversion could benefit your enterprise projects? 15 day free trials of both our Subversion MultiSite and Subversion Access Control products are available now.


Poll Results: Which OS does your Subversion Server Run On?

As a successful and established open source project, Apache Subversion has a vibrant community of users – but how exactly are they using Subversion? Last month, we found out which SVN client is the most popular, and a few weeks ago we posed another question to the community: which operating system is your Apache Subversion server running on? The results are in and, once again, Windows comes out on top:


60% of respondents are running their server on Microsoft Windows, and in a previous poll we found that over 60% were using the TortoiseSVN client (which isn’t surprising considering how easy it is to get started!)

If you’re a Windows user (and, judging from the poll results, there’s plenty of you out there in the Subversion community!) we have lots of useful tutorials aimed at your OS of choice, including some hidden TortoiseSVN commands.

Have a question you’d like us to put to the Subversion community? You can either post it here, or Contact Us directly and we’ll try and feature it in future polls.


Getting Started with Apache Subversion

As the world’s most popular version control system, Apache Subversion has plenty to offer newcomers:

1. It’s an established project – accepted into the Apache Incubator in 2009 and graduating a year later, today Subversion is an Apache Top Level Project maintained by a global community of contributors.

2. Rich ecosystem – Apache Subversion users have access to countless free client tools, GUIs and plugins developed by the community. SVN also integrates with most of the major IDEs, including Eclipse and Microsoft Visual Studio.

3. Free Community Support – Have a question about Subversion? There’s no shortage of mailing lists and forums (including SVNForum.) In many cases, your question will have already been asked (and answered) by someone else. If you can’t find the answer, you can always post it yourself and the community will be happy to help you out.

4. Professional Support – Subversion has a great community of users who are always willing to answer queries, but mailing lists and forums aren’t always the ideal place to reach out to when disaster strikes your enterprise deployment. At WANdisco, we offer professional support services for Subversion, that includes 24-by-7 worldwide coverage, guaranteed response times, and indemnification coverage, for those who need that added security.

5. Powerful branching and merging functionality – Branching and merging can be a pain-point for Apache Subversion users but, used correctly, branching and merging can be Subversion’s greatest strength. We have some free branching and merging refcards, to help you master these potentially tricky issues.

Apache Subversion has plenty to offer users, but if you’re new to SVN – or even version control in general! – it can be difficult to know where to start. To help newcomers get off to a flying start with Subversion, we’ve just released a ‘Getting Started with Subversion’ refcard. This refcard covers all the essential information you need to get going with Subversion, including what Subversion actually is, the basic work cycle you can expect to encounter, and an installation guide. It then demonstrates how to create your first repository and covers the essential commands – svn checkout and svn commit.

Getting Started with Subversion’ is free to download. We’ll be adding more refcards in the coming weeks, so keep checking back for all the latest Free Training Content.

Resolving Conflicts in Subversion

When you are performing a commit in Subversion, you may very occasionally encounter the dreaded Subversion conflict, and your commit will fail. A lot of drama is made about conflicts in version control, but Subversion has all the functionality you need to quickly resolve conflicts when they arise.

Conflicts occur when you attempt to commit a file that has been updated in the repository since you performed your check out, e.g:

    • File A is checked out by Person A.
    • Person B commits a change to File A in the repository.
    • Person A makes a change to File A, and tries to commit file A to the repository. Subversion will flag up a conflict.


When you encounter a conflict, the first step is to run an update on your working copy:

svn update (path)

Subversion will then attempt to merge the repository’s changes into your working copy, while retaining the changes in your working copy. If the changes affect different sections of the file (e.g different lines of code) the server will successfully merge the changes, and you will be able to complete your commit. But, what if you’ve modified the exact same part of the file, and Subversion is unable to merge the changes? Subversion will mark the file as being in ‘conflict’ and the problem will need to be resolved manually.

To resolve the conflict, open the corresponding folder in your working copy. You will see three versions of the conflicted file – two with filename extensions based on their revision number, and one without a numerical extension, which is the working file. The file with the highest numbered extension is the repository’s most recent file, and the file with the lower revision number is your local file. There are three possible ways to resolve this conflict:

    • Replace the repository’s version with your local version.
    • Keep the repository’s most recent version.
    • Manually merge the changes from the repository’s version and the local version.


Once you’ve decided which item to keep – or finished manually merging the changes into a single file – replace the working file with the finished item, and delete the duplicates generated by Subversion. Now, you will be able to successfully complete your commit. It is also worth bearing in mind that in some situations (particularly those where your changes are minimal) it may be quicker to delete your working copy of the conflicted file, perform an update and then reapply your changes to the freshly checked out file, rather than trying to resolve the conflict.

Avoiding Conflicts

Although Subversion has functionality for resolving conflicts, the best cause of action is to avoid conflicts in the first place. There are several measures you can take to avoid running into conflicts in Subversion:

    • One of the most effective ways is also the simplest: communicate with your colleagues. Discussing what you’re working on, is an easy way to avoid unintentionally working on the same files.
    • A more heavy-handed approach, is to employ Subversion’s lock command. Subversion is built around a ‘copy-modify-merge’ model, but there are times when a ‘lock-modify-unlock’ model may be appropriate (for example, when you are working on image files, which cannot easily be merged.) Locking in Subversion allows the ‘lock owner’ to exclusively modify a file in a repository (note that it is currently not possible to restrict access to an entire directory tree.)

To create a lock, create a property on a directory tree called ‘lock’:

svn propset lock

Commit this property to the repository (note that it doesn’t matter what value the lock property is set to.) If anyone tries to commit to a locked file, Subversion will have to authenticate that they are the lock owner, before it allows the commit. Just remember to unlock the file when you’re done!

    • Perform an ‘svn update’ on your working copy whenever a colleague commits a change that may affect you.
    • Commit frequently – this will reduce the complexity of conflicts, when they do occur.


Subversion Tip of the Week

Quickstart: Getting Started with Jenkins and Subversion

The Jenkins open source continuous integration server can be a valuable tool for Apache Subversion users. It can be configured to watch for code changes in repositories, to automatically perform builds, to notify users, and perform other useful tasks on both remote and local machines. The easiest way to integrate Jenkins with Subversion, is through uberSVN and its integrated uberAPPS store. In this easy, five step guide, we’ll walk you through installing Jenkins in uberSVN.

1) Select the ‘uberAPPS’ tab from within ‘uberSVN’ to be taken to the store front, where you can select Jenkins.
2) From the Jenkins product screen, click ‘Download Now’ to download Jenkins.

3) Once the download is complete, click ‘Activate.’
4) You will notice a new Jenkins tab appear. Select this tab to go to uberSVN’s integrated Jenkins screen.

5) From here, you can optionally decide whether to make Jenkins visible to all users, or define exactly who can access the tool.

Get started with uberSVN now – download it for free from

Need more Subversion know-how? After getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012, bringing the Subversion community sessions covering everything from Subversion’s future, to expert-led best practices workshops, as well as the unique opportunity to meet the core Subversion committers.