Monthly Archive for December, 2011

Happy Holidays from WANdisco

2011 has been a great year for the Subversion community; not only did we see the release of a major Subversion update but, thanks to the hard work of Apache Subversion’s great community of committers, users and developers, we saw two maintenance releases within the space of a few months!

As an active member of the Subversion community, this has also been an exciting year for WANdisco: we were honoured to receive a range of industry awards, launched a brand new ALM platform and an integrated app store especially for Subversion, and, most importantly, stepped up our involvement with the community, through free training webinars and plenty of new blog posts! Check out our timeline, for an overview of everything that’s been going on at WANdisco HQ in 2011:

We’ve already got plenty of exciting things planned for 2012, so stay tuned! But for now, we want to take this opportunity to wish you a very happy holiday from everyone at WANdisco!

WANdisco’s December Roundup

This has been a busy month for everyone at WANdisco! Not only did we see the release of Subversion 1.7.2, which brought even more enhancements to the 1.7 series, but we also released the Blake edition of our open ALM platform for Subversion, uberSVN. This release marked a major update to the uberAPPS store, which makes it easier than ever to add new apps. uberSVN Blake also features the latest and greatest release of Apache Subversion, version 1.7.2. This month, you might have noticed that we also launched a brand new section of the blog – Tip of the Week. Keep checking back every Monday, for a brand-new tip aimed at helping you get the most out of Subversion. Inbetween all that, we still found time for some fun, which included building an office gingerbread house, and getting plenty of photographs taken by our friend and Electric Works neighbour, Matt Lollar. And, of course, December wouldn’t be complete without an office Christmas party!

Check out our December newsletter, for even more info on what we’ve been up to this month!

Busy Developer’s Guide to Subversion Best Practices

Need some quick tips on Subversion best practices, covering everything from structuring your repository, to avoiding merge hell, and advice on testing? In this post, we share some rapid-fire advice for busy developers who need to get the most out of Subversion straight away.

Repository Structure

Subversion gives users the freedom to structure their repository according to a project’s particular needs, but if you don’t implement a logical project layout, you’re running the risk of creating an administrative nightmare. Here are some general rules worth bearing in mind when creating a new Subversion repository, to ensure all that freedom doesn’t lead to complications!

  • The trunk shouldn’t break – the trunk should always be stable, and should always compile. To ensure the trunk doesn’t break, all risky development should be confined to the branches, and CI and automated regression testing should also be considered, to ensure there is no regression in the trunk.
  • Use tags – tags should be used to make snapshots of your project at certain points along the development process (e.g tagging a copy of ‘Release 1.0’.) It can also be useful to make snapshots of your code before implementing major new features, in case you need to roll back to before a feature was introduced.
  • Working copies should always be checked out from the top level of the branch/trunk – i.e /trunk or /branches/(branch name)
  • The root directory of the working copy should be named after the branch that it is checked out from (e.g “ProjectA”)
  • Make structural changes to the trunk – structural changes to the repository (directory or file renaming, and directory or file deletion) should always be performed on the trunk, at a time when there are no outstanding branches waiting to be merged. This can help teams avoid serious merge conflicts.

Want more advice on setting up your repository? For more information, see our post Subversion Best Practices: Repository Structure

Branching & Merging

Branching and merging can be a pain-point for Subversion users, but when used correctly, branching and merging is one of the most powerful tools at your disposal. Here are some tips for avoiding merge hell – and that dreaded merge conflict!

  • Make use of log messages – when performing merges, it is good practice to leave as much information in the log message as possible (what changes were made, why, and by whom, etc.) Remember, the more information you provide, the easier it will be months down the line, when you need to find out if a particular branch was ever incorporated into the trunk.
  • One thing at a time – when performing a merge, it is important to isolate the merge (i.e only make changes that are necessary to resolve the conflict) – do not add any additional planned development before performing the commit. Likewise, do not commit unrelated code changes in the same commit (i.e two bug fixes in one commit). Both of these actions make it difficult to distinguish where changes originated from, and can cause major headaches if the team decides to roll back to a particular revision.
  • Use branches – branches should be created for new features and major bugs. Bug fix branches are particularly useful, as they allow bugs to be worked on immediately, regardless of the work underway in the trunk, or in neighbouring branches.
  • Use ‘svn update’ – branches should be kept up to date with changes committed to the trunk, by regularly running ‘svn update’. Even if it seems your changes have little to do with the rest of the team, by the time you’ve finished perfecting your branch, the trunk may have evolved to the point that it’s a nightmare to merge your changes.
    It is good practice to also run ‘svn update’ on the working copy before you begin making any changes. This ensures that your working copy is up to date with the latest version in the repository.
  • Commit often – commit small changes frequently, as oppose to committing many small changes in one large chunk. This will help reduce the chances of encountering merge conflicts, and will help reduce the complexity of conflicts that do occur.
  • Delete unwanted branches – branches that are no longer required can be deleted. There are several reasons why you may decide to delete a branch, but the main ones are:

    – To reduce clutter.
    – A successful merge has been performed, and the branch is now redundant.
    – A successful reintegration merge has been performed, and any future reintegration of that branch will confuse Subversion’s merge tracking capabilities.

Branches should not be deleted to reduce the repository size, as deleting branches does not actually remove them from the repository, it just removes them from the HEAD revision.

For even more information on branching and merging, check our out blog on Best Practices for Merging in Subversion


And lastly, test everything! Get into the habit of systematically testing every feature and bug fix implemented after merging, and consider CI and assertion testing on feature branches, which are useful for indicating code maturity and progress. As a minimum, automated regression testing should occur on the build of the feature branch.

That Was the Year that Was – uberSVN & All That…

I suspect that I will always remember 2011 as the year when the curtain came down on one of the true greats – Steve Jobs. Great, not just in my world of Silicon Valley techies, but great for just about everyone else on the planet. Even though most of us never knew him we feel like we must have. We seem to use his stuff just about every day.

Apple’s success has had and will continue to have a massive impact on the design of computer systems and products. When we were thinking about uberSVN the very first thought we had was about the relationship between the product and the user. Ten years ago I don’t think that would have been the case. I guess you could call it ‘the pre-iPod days’ (the first iPod was released in October 2001 and was cast as “1,000 songs in your pocket”) before that, according to Jobs, music players were either “big and clunky or small and useless”.

Our customers told us that ‘old fashioned’ ALM was big-and-clunky; and they’re probably right! In many cases they were moving away from these ‘dinosaurs’ to a best-of-breed approach. Like Subversion for source control, JIRA, Redmine or Trac for defects & wiki, Review Board for peer code reviews, and so on.

When we launched uberSVN in April I talked about empowering users by giving them choice. Freedom to choose any combination of ALM tools that best fit the business requirements be it price or functionality, open source or closed source. How’s it doing? In short – amazingly well! To our delight it’s being used everywhere from Fortune 100 companies to the US Senate. I even got my 11 and 12 year-old children to install it on their MAC books – it took them only 5 minutes! Not sure how much use they get out of Subversion – but they did get double pocket money for their efforts! That really is the point of uberSVN. We have made an extremely powerful but complex product extremely easy to use and install by anyone and I think we succeeded in that regard.

We quickly followed-up with uberApps. Another ‘first of a kind’ product with an enterprise AppStore for software development tools. Now, with just a single click, it is possible to install a build & test product like Jenkins or even buy external QA resources from crowd-sourcing vendor uTest. This is another step in making ALM both usable and useful. Anyone, and I mean anyone can deploy these apps without special knowledge, experience or skills.

These products were developed in my hometown, Sheffield. It was our Christmas party there the other week and it really was astonishing to see how quickly we have grown. From a small office where we would “see what happens” we have grown to almost 40. There was a lot of laughing behind hands from my ‘friends’ from the south and lot’s of “ooop north” jibes. Well, in between wearing flat caps and racing whippets, the Sheffield team delivered an award-winning piece of software. uberSVN won 2 awards in the first year of its launch and we have seen almost 50,000 downloads.

Apache Subversion also continues to grow. Subversion is still the ‘King’ of source code management. More traditional Enterprises are turning away from old-fashioned / big-and-clunky ALM for Subversion. And SVN 1.7 (also released this year) has delivered a much-needed performance boost. Throughout the year I have been embroiled in various spats with the Giterons (Git fundamentalists who believe in the inerrancy of Linus) but only this month I have spoken to 3 or 4 companies that tried Git but had to pull it out due to various-and-sundry issues. Much more on that early in the new year, when we might just have a solution for those looking to use Git as more of a client to a central SVN server of record…

There was also some politics earlier in the year when one of our competitors used some pretty underhanded tactics to besmirch our good name. Unfortunately for them it worked quite well in our favor. We are, and always have been a big supporter of the ASF (we are even the only Subversion contributor to also be a sponsor). In fact, at the time of writing, we are in the process of proposing a new project for the ASF incubator. Again, lot’s more on that in the new year.

We also took some steps earlier in the year to solidify the Subversion community by acquiring I think we have done a pretty good job of updating the site software, Subversion Liveeradicating spam and generally making the site a useful, free resource for every SVN user. As part of our efforts for the SVN community we also hosted the first Subversion user conferences. Audiences in San Francisco, Boston and London attended “Subversion Live”. We are hosting Subversion Live again later in the year with a extended program.

So 2011 was a great year here at WANdisco but 2012 should be even better. We have several major product launches planned including a new (free) open source defect tracker / wiki, uberSVN Team, uberSVN Enterprise and a solution to the Git/SVN conundrum. In the words of ‘Potato Claus’ (the lead character in my kids’ favorite book from a few years ago) may I take this opportunity to wish everyone Happy Christmas, Kwanzaa, Chanukah, Winter Solstice, and also local and regional winter holidays and celebrations.

Here’s a rather nice pictorial representation of 2011 from a WANdisco perspective (click to enlarge):


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

Subversion Tip of the Week

Command Line Quickstart

Apache Subversion has no shortage of useful GUI clients, but it’s also useful to know how to interact with Subversion from the command line. Here’s our five-step guide to getting started with command line Subversion in Windows!

1) Subversion commands are entered via a terminal window. To open this in Windows, press the ‘Windows key’ and ‘r.’ This will bring up the ‘Run’ dialog box. Enter ‘cmd’ and hit ‘Ok.’

2) To create your first repository, run the following command:

svnadmin create {location where you wish to create your working copy} {working copy name}

3) Now you have created your repository, the next step is to checkout a working copy. This is done with the following command:

svn checkout {repository URL} {working copy location}

4) Now you have a local working copy on your machine. Edit away!

5) When you are ready to commit your changes back to the repository, run the ‘svn commit’ command followed by “–message” and an appropriate log message, and finally, the location of your working copy.

svn commit “–message” {log message} {working copy location}

Your changes have now been committed to the repository!

Office Photo of the Week

This week, WANdisco’s management team came over from California to visit the Sheffield, UK, office, so we took some time out from finishing off the latest and greatest release of uberSVN, to have our friend Matt Lollar take some photographs of the entire WANdisco team together. The Yorkshire Post published their favourite earlier in the week, but in the office we’re big fans of the Electric Work’s slide, so we just had to share this photograph of the team stood in front of the slide!

2011 has been a great year for WANdisco and the Subversion community, and the company has really grown since our last team photo. A big welcome to all our new starters!

uberSVN ‘Blake’ Released with Streamlined Subversion App Store

The holiday season may be nearly upon us, but things are far from quiet at WANdisco! We’ve been busy working on our uberSVN open ALM platform for Apache Subversion, and are pleased to announce that uberSVN 11.12 (Blake) is now available! This release marks a major update for uberAPPS; uberSVN’s integrated app store for extending Subversion. With uberSVN 11.12, we have made it even easier to add apps to the uberAPPS store, and have added the option of making installed apps visible or invisible, on a per-user basis. Other key enhancements include:

  • A more helpful screen when uberSVN is unable to connect to the uberAPPS store.
  • Repository support for anonymous reading. When enabled, the repository can be accessed/read without the need to authenticate.
  • The option to switch to and from the latest version of Subversion – version 1.7.2 – with the innovative SVNswitch tool.

As you may already know, uberSVN is developed entirely in Sheffield, UK (it was even awarded the prestigious Made in Sheffield mark earlier this year!) so what better way to codename our releases, than after local Sheffield pubs? uberSVN 11.12 is codenamed ‘Blake’ after the Blake Hotel pub in Walkley, Sheffield, and after successfully releasing uberSVN 11.12, we thought there was no better way to celebrate the release of Blake, than having a few pints in the Blake!

uberSVN is free to download and easy to install, and gives users the freedom to build their own, customized ALM platform from the open and closed components they want to work with. It also comes with social coding capabilities, to make collaboration easier – particularly across distributed teams! Simply visit to download the brand-new version 11.12; or check out our Top 10 Reasons to Try uberSVN, for more info on what uberSVN has to offer!

More information on uberSVN 11.12 is available at the Release Notes.

Subversion Tip of the Week

The Oops Command

Often when you are changing code, you will realize that you have meandered down the wrong coding path. You can take the manual approach and try to back out of your changes but Apache Subversion gives us an easier way. It is called the revert command.

If you want to have a file restored to where it was when you last checked it out, or when it was last updated, you can use the revert command to restore a file (or files). This command will appear in the context menu from your working folder if any files have been changed. Be aware that if you select a changed file and then right-click, you will only be reverting that file (or files) you have selected. To make sure you will be affecting all the files that have been modified, either right click on the top of the working folder or make sure you have selected (using the Ctrl/Key) all the files you may want to convert.

Below is an example of the first step of the revert command. Here you can decide which files to revert and which to ignore.

You can check the box of any file you may want to revert to what it looked like when it was checked out or updated. Be aware that both a files’ changes and any changed Subversion properties will be changed by the revert command.

At the bottom of the form there is a button labeled “Delete unversioned items…” This will present you with a form where any files that you have added since doing a checkout (but not added with the Subversion ADD Command) can be selected, and then deleted.

The revert command also works with folder changes. Below you see the effect of running the revert command after adding a new folder (“newfolder”) and renaming a folder (“reports” was renamed to “User_reports_renamed”).

The effect of a rename shows up as the deletion of the old folders and addition of the new (renamed) folder.

Every week WANdisco’s Head of Training Mike Lester will publish a tip to help you get the most out of Apache Subversion. Mike also delivers free, bi-weekly training webinars on topics ranging from branching and merging best practices, to Subversion in the enterprise, and advice on making Subversion agile. Register early, to avoid missing out! Enterprise Training is also available.

Office Photo of the Week

This week, we received our first present of the holiday season at the WANdisco office, from our friends at Huston Grey: a kit to build our very own office gingerbread house! We know it isn’t the holiday season yet, but we couldn’t help ourselves – check out our house-building efforts below (our Subversion Sherpa is a fan!)

Thanks to Clare MacKenzie and the Huston Grey team, for helping us get into the holiday spirit!

Making Subversion Agile

It’s been ten years since the Agile Manifesto was published, and agile is still a buzzword for the software industry. When employed correctly, agile practices can save on costs by promoting flexible, incremental development, a continuous integration environment and effective communication between team members, and between the development team and the customer. Agile practices can help organizations avoid unplanned rework and QA, and ultimately hit deadlines. Crucially, the Agile Manifesto focuses on the realities of software development, rather than on documentation, plans, contracts, processes and tools. The values that form the cornerstone of the Agile Manifesto are:

  • Individuals and iterations over processes and tools – find the tool that allows your particular team to implement a successful workflow, regardless of whether that’s a high-tech or a low-tech approach. Selecting the wrong tool can distract developers from every agile project’s ultimate goal: delivering value.
  • Working software over comprehensive documentation – documentation is important, but in agile, working software is the ultimate goal, and producing exhaustive documentation should not get in the way of that. It’s all about finding the right balance.
  • Customer collaboration over contract negotiation – regular contact with customers increases the chances of discovering problems early on, before they begin to snowball out of control.
  • Responding to change over following a plan – plans are subject to change, as new information, requirements and challenges emerge. Agile teams need to be able to respond to these changes.

Also worth considering when adopting an agile approach, are:

  • Feedback – constantly evaluate your working process, to ensure you are adding the most possible value. This is essential in fast-moving teams.
  • Have working code at all times – executing application code is the best sort of feedback on the health of a project. In addition, a broken build forces teams to delay sharing changes, which ultimately leads to riskier integrations. Nothing slows down a team like a broken build.
  • Continuous integration environment – frequent, ongoing quality control over the traditional practice of applying quality control only after development is complete. This typically reduces the time taken to deliver software.
  • ‘Everyone is responsible’ – it’s important to maintain a culture where everyone is responsible for maintaining working code. A broken build should be an all-hands-on-deck task.
  • Incremental development – frequent integration, testing and evaluation of code is crucial to agile development, allowing problems to be detected and resolved earlier, and helping to maintain working code.

An effective SCM solution is a crucial factor in becoming agile, and there are several options open to organizations who want to implement a Subversion-based SCM solution:

1) Central Subversion Server

A central Subversion server does have the advantage of all developers working from a single, consistent copy of the repository. There are also advantages from an administrative perspective, because there is only one server at a single site to worry about. However, as the number of remote sites and users grow, the coordinated performance between the central server and remote locations can become an issue. This encourages developers to checkout infrequently, which makes continuous build integration impractical as the latest changes aren’t available from all development sites. Ultimately, you only uncover merge conflicts and other problems when remote users finally commit their code, and this has to be addressed manually, often requiring significant, unplanned rework and QA.This can cause deadlines to slip. The single point of failure inherent in this approach, prevents users from accessing the single central repository when the network connection is lost, the server crashes, or it has to be taken down for routine maintenance.

2) Proxy Server

Proxy server, master/slave solutions such as svnsync do provide local access to read only copy with the master, which partially solves the access and availability issues for remote developers, but commits and other writes can only be performed against the master. In some respects, proxy server solutions have the same single point of failure and latency issues, as a single server architecture. Sites can often end up working with stale versions of source code files, due to time lags between changes being written to the master repository and those being replicated to the read-only slave. Consequently, you end up with much of the same merge conflicts and broken build issues encountered with a central server architecture. The other factor to take into consideration, is that with a proxy server solution there’s no built-in capability for catching an error and retrying the failed transaction.

3) Subversion MultiSite

WANdisco’s Subversion MultiSite solution combines Apache Subversion with value-added functionality designed to help teams stay agile:

  • No single point of failure – all repositories are fully readable and writeable, and remote site developers aren’t dependent on the centralized build team if they need to do a build and test. This eliminates the potential bottleneck of a single point of failure.
  • Automated failover – allows individual servers or an entire site to be taken offline for planned outages without interrupting user access, making full 24-by-7 operation possible.
  • Built-in continuous hot backup and automated recovery – Replication is triggered automatically whenever a user connected to any server issues a write command. The commit is then propagated out to any other sites, ensuring that distributed repositories are kept continuously in sync. Whenever a server comes back online following an outage, it automatically resynchronizes with the other servers in the cluster. Third party solutions aren’t necessary for backup recovery, and the risk of data loss and extended downtime associated with manual recovery are eliminated.
  • Continuous build integration – MultiSite’s peer-to-peer architecture, unique active-active replication capability, and functionality for keeping distributed Subversion servers in sync, provides the support necessary to maintain that all-important continuous build integration.
  • Run builds at every site immediately – eliminates the time wasted while waiting for a build to happen in a different time zone.
  • LAN speed performance – users at every location experience LAN-speed performance for both read and write operations.
  • Rapid identification of problems – thanks to the Active/Active Replication technology, merge conflicts and other problems get caught and fixed as they occur. This is essential to recreate the same development experience that exists when everybody is in the same location.

For more information on the benefits of Subversion MultiSite, check out Forrester Research’s Total Economic Impact study of a Global Fortune 500 company using Subversion MultiSite.