Crowdsourcing Comes to uberSVN

You may remember we announced a new release of uberSVN at the end of 2011, bringing a major update to the integrated uberAPPS store that was designed to make adding new apps easier and quicker. Today, we are announcing the first of our new additions to the revamped app store: uTest’s range of testing types for web, desktop and mobile applications.

uTest covers all the major operating systems, and is backed by a community of over 45,000 on-demand professional testers from 180 countries. uTest enables development teams to launch higher quality products quicker, and to control the cost of testing. At WANdisco, we’re proud to announce this partnership with uTest, and will be offering uberSVN users two packages of uTest services:

Bronze

  • 5 professional testers located throughout the US and Canada
  • Testing across a selection of the most popular OS versions, browsers or devices relevant to your particular app
  • Real-time communication with your testing team

Silver

  • 10 professional testers located throughout the US and Canada
  • Testing across a selection of the most popular OS versions, browsers or devices relevant to your app
  • Real-time communication with your testing team
  • Online technical support from a uTest project manager

New to uberSVN? The free-to-download, easy-to-install open ALM platform can be downloaded from http://www.ubersvn.com/download. Existing uberSVN users can easily purchase uTest from within the integrated uberAPPS store. Ready to get started? Check out our step-by-step guide to adding uTest to uberSVN.

We’ll be making another exciting, uberAPPS announcement soon. Keep checking back for the latest news!

Subversion Tip of the Week

Filtering Log Messages

When you have 40-50 revisions and a couple of projects, finding a particular revision is pretty easy. When you have three years of history, 20 active projects and revisions in the high five or low six digits, locating a specific revision can be an adventure. (And by adventure we’re not talking about a trip to Disneyland, we’re talking about the running out of gas 20 miles from the nearest town in 2 feet of snow, at night, type of adventure.)

First of all, finding a specific revision becomes a lot easier if you have some standards:

  • Always put in log messages. Not just for commits, but for copies, deletes, renames, anytime you are prompted for one.
  • For certain activities, have a defined structure. “Fixed bug #1431”, “Added Feature #5r31a”, “Created Branch”, “Deleted Branch”.
  • Use training, published “Policies and Procedures”, hook scripts and active management to ensure that proper log messages are added.

Luckily in TortoiseSVN you can filter (search) for log messages. In fact, you can search for log messages as well as the text of authors, dates, and paths. But mostly you will search on log messages.

Let’s look at an example of filtering. In the picture below we have a standard of entering the log message “Working on Bug #nnnn” or “Fixed Bug #nnnn” depending on whether the development effort is underway or finished. The first image shows our results, pre-filter and the second picture shows filtering on the bug number “5100”.
Log messages with no filtering.

Filtering on the string “5100”.

But let’s say we want only those revisions with the bug number “5100” but not containing the string “Working”. This would give us the revision where the bug was fixed.

The filter “ 5100 -Working” would look for all messages containing the string “5100” but NOT the string “Working”.

The minus sign (-) means without.

Note: The filter “5100 -WoRkIng“ would generate the same results. Case is ignored.

Other examples of filtering:

  • Sort -Marketing +Finance – searches for strings containing both Sort but not Marketing, or strings which contain Finance.
  • !Sort Report – searches for strings which do not contain both Sort and Report
  • “Finance Reporting” – searches for the literal expression “Finance Reporting”

You can also use regular expressions to limit your searches by selecting this option. An example of a regular expression would be:

  • Market(ing|ers) – which would find messages with Marketing or Marketers.

But that will be covered in another blog.

WANdisco Supports new Apache Bloodhound Project

It’s no secret WANdisco are big fans of open source, so we’re excited to see that the Bloodhound project has taken its first step to becoming a fully-fledged Apache Software Foundation project: Bloodhound has been voted into the Apache Incubator by the Apache community!

The Apache Bloodhound project will provide a software collaboration tool based on the code base of the well-known Trac project, and will include issue tracking, a wiki, and repository browsing. It will further build on Trac by incorporating some of the most popular plugins, to create a more complete distribution than your typical Trac installation. One of the Apache Bloodhound project’s core goals, is to create a strong developer community around the Trac code base in a vendor-neutral location. Trac has already included a potential Bloodhound project on its list of derivatives. At WANdisco, we are excited to get involved in this new project, by sponsoring a number of the initial committers.

Although WANdisco are sponsoring some of the initial committers, one of the major aims of Apache Bloodhound will be to create a vibrant developer community, and any interested committers will be able to contribute to the project. Interested in getting involved? Check out the Bloodhound webpage for more info.

Subversion Tip of the Week

Hidden TortoiseSVN Commands

You may already be familiar with TortoiseSVN’s context menu, but did you know that if you hold down the shift key, you can access an extended context menu? This menu has some additional options.

1) Merge reintegrate – merges all the changes from a branch back to the trunk.
2) Break lock – this command breaks someone else’s lock (useful in emergencies!)
3) Delete unversioned items – this opens a dialog that lists all the unversioned items in the working copy. From here, you can select which unversioned items to move to the recycle bin (of course, they can be recovered from the recycle bin, if you make a mistake!)
4) Delete (keep local) – deletes an item from the repository, but maintains it locally as an unversioned file.
5) Diff with URL – displays what changes have been made on a particular branch (for users working on the trunk) or what changes have been made on a trunk (for users working on a branch.)

The latest version of TortoiseSVN can be downloaded now.

Up to 50% Discount on Enterprise Subversion Training

To celebrate the start of a new year, WANdisco is offering you the opportunity to get organized and arrange all of your Enterprise Subversion training in advance, while enjoying up to a 50% discount.

With our new ‘uberDollars’ training tokens, Apache Subversion users can take advantage of a range of discounts on all of our Enterprise Subversion training courses, which range from an introduction to the core concepts of Apache Subversion, to training for Subversion Administrators, and even a ‘Train the Trainer’ programme for organizations with in-house training staff.

Customers purchasing tokens in advance, will receive the following discounts:

  • A 15% discount on $10,000 tokens
  • A 20% discount on $25,000 tokens
  • A 30% discount on $50,000 tokens
  • A 50% discount on $100,000 tokens

We can also create custom uberDollars packages to suit you, simply specify ‘Other’ when filling in our uberDollars form, and we’ll be in touch.

Please note that this is very a limited New Year’s offer, and it will expire on January 31st, 2012, so act early to avoid disappointment. For more information on our Enterprise Subversion training, or to enquire about purchasing uberDollars, visit our uberDollars page now.

Subversion Tip of the Week

The “Import in Place” Procedure

I have a large project that has lots of folders, and I only want half of them to be imported into Apache Subversion. What do I do?

The solution to your problem is something called “Import in Place”. WANdisco covers this topic as part of the Subversion User Class.

So here is our situation:

We have some development that is not yet part of Subversion.

As development evolved, a number of folders have been created for numerous reasons, that all have the same characteristic. We don’t need their contents under version control. The information could be simply unneeded or should not be seen for some reason. (Privacy, legal, embarrassing.)

We are experienced enough to know that importing all the folders and then deleting the ones we don’t want is not a great solution. (a.) The wasted storage still takes place or (b.) Anyone could view the contents by looking at the earlier version of this project.

We could manually import all the needed folders one-by-one but that might take a lot of time or effort or more importantly, result in accidentally skipping one or more folders.

Here are the steps:

  • Create your top level folder in the repository. (In this example the repository is “inplaceDemo” and the project is “BankDocSystem” and our top level is the trunk folder.)
  • Checkout the top level to the folder that holds your current development code. (See Figure 1) You will get a warning that the local folder is not empty. Now you have a versioned top level folder with unversioned content.
  • Use the ‘TortoiseSVN Add’ command on this folder.
  • Uncheck the files/folders you do not want to be part of version control, or unselect all the boxes and then select the files/folders you want.
  • Perform the commit command.
  • Look in the repository browser for your populated project.

This technique can save a lot of time and hopefully a few errors.

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

Testing

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 SVNforum.org. 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):