Monthly Archive for October, 2011

WANdisco Go Pink for Breast Cancer Awareness

At WANdisco, we released our inner pink today in support of the 50,000 people in the UK who are diagnosed with breast cancer each year. We spent Pink Friday in our best pink attire, eating pink cupcakes and buying raffle tickets, all for a good cause! Money raised from the Pink Friday fundraising campaign goes towards helping fund vital services, including the helpline, support groups for people who have been diagnosed with breast cancer, and information points in hospitals. The Breast Cancer Campaign have plenty of other events lined up, so visit their website now to find out more! Here’s WANdisco’s marketing team, rocking the pink look for Breast Cancer Awareness!

Top Ten Reasons to Switch to Subversion

It’s no secret that WANdisco are big fans of Subversion! But we know that Subversion is far from the only revision control system on the market, so what makes Subversion so special? Here are our Top Ten reasons to give Subversion a go!

1) It’s Established – Accepted into the Apache Incubator in 2009 and graduating a year later, Subversion has been an Apache Top Level Project for well over a year, and is today maintained by a global community of contributors. Furthermore, in 2007, independent technology and market research company Forrester Research identified Subversion as the sole leader in the Standalone Software Configuration Management category, and as a strong performer in the Software Configuration and Change Management category.

2) Increasing corporate adoption of open source – Open source is enjoying increasing acceptance within the enterprise. There are plenty of reasons to adopt open source solutions, but cost is the most obvious one. With closed source solutions, there’s the initial outlay, but there can also be some hidden extras: the expense of ongoing upgrades, extra licenses if the team expands, training costs, etc. Open source solutions reap the benefits of potentially thousands of developers, all contributing their expertise to the same project. This typically means shorter release cycles than some closed source projects, and this sort of collaborative development also encourages transparent, archived communication through mailing lists and forums. This communication can be an invaluable (and free!) source of information for the Subversion user. As an open source project with all of this to offer, it’s easy to see why Subversion is gaining popularity within the enterprise! Many Fortune 1000 companies use Subversion: AT&T, Intel, Honda, Nokia, Juniper Networks and Motorola all rely on WANdisco’s Subversion solutions.

3) Vibrant ecosystem – Apache Subversion has a vibrant ecosystem of users who can be contacted for advice via mailing lists and forums. This ecosystem also includes many free client tools (including TortoiseSVN) GUIs and plugins, developed by the community. In fact, there are integrations for most – if not all – of the major IDEs: Eclipse, Microsoft Visual Studio, etc.

4) Commits as true atomic operations – commit operations to any number of files and directories are automatically published as a single atomic transaction. Every commit operation will either succeed completely, or fail completely; this guards against a situation where some of the committed files make it into the repository, and others do not. Where atomic transactions aren’t supported, interrupted commit operations can lead to repository inconsistencies or corruption.

5) Established professional support options – open source solutions can be a real asset to a project, but there are some common concerns many organizations have, regarding open source. Subversion has a great community of users who are always willing to help out, but mailing lists and forums aren’t always the ideal place to reach out to when disaster strikes your organization! Thankfully, established open source projects often have professional support options that can alleviate these worries, and Subversion is no exception! At WANdisco, we offer professional support services for Subversion, that include 24-by-7 worldwide coverage, guaranteed response times, indemnification coverage, and even help migrating to the latest and greatest version of Subversion, Subversion 1.7x.

6) Branching – Subversion supports the concept of ‘branches,’ lines of development that exist independently of another line. Branches allow developers to work on code, independently of the work going on in the trunk. None of the changes made within a branch are seen by people working in the trunk, or in any other branches, until a merge is performed. Subversion has a range of functionality for users working with branches, including commands for maintaining parallel branches, and the ability to make parts of the working copy reflect different branches. Subversion also remembers which branches are related to one another.

7) Merging – in Subversion, when multiple developers are working on the same project simultaneously, files do not need to be locked to ensure that only one developer at a time has access to the central repository of those files. Instead, Subversion encourages ‘merging,’ which is the act of replicating changes from one branch to another. Merging increases productivity, by eliminating time wasted by developers queuing up to access the same source file.

8 ) Easy to administer – when compared to competing revision control systems, administrative overhead for Subversion is fairly light.

9) Subversion 1.7 – We can’t think of a better reason to start using Subversion than a brand-new, major release! Subversion 1.7 introduces some long-awaited functionality, including:

  • WC-NG – a complete rewrite of the working copy metadata system.
  • Pristines – a new way of storing text-bases in 1.7.
  • Merge-tracking enhancements – over 40 improvements to merge tracking.
  • HTTPv2 – a new HTTP protocol variant designed to enhance performance between Subversion clients and the server.
  • A new in-memory caching system for FSFS repository backends.
  • Network compression – a protocol for avoiding CPU bottlenecks on the compression side.
  • svnrdump – a new client tool that provides the same functionality as svnadmin dump and svnadmin load, but on remote repositories.

10) Open and extensible architecture – Subversion can be used as the foundation for your software development lifecycle. This is exactly what we have tried to do with uberSVN, WANdisco’s open ALM platform for Subversion! With uberSVN, WANdisco set out to transform Subversion into an open, extensible platform for ALM that gives users the widest choice of toolsets, with no vendor lock-in. uberSVN is free to download, easy-to-install and easy-to-use!

Have we convinced you to give Subversion a go? The latest Subversion binaries can be downloaded from the WANdisco website. And if you want to find out more about uberSVN, our ‘Top 10 Reasons to Try uberSVN’ blog post is a great place to start!

What Do ‘Trunk,’ ‘Branch’ and ‘Tag’ Really Mean?

‘Trunk,’ ‘tags’ and ‘branches’ are common conventions in Subversion, and most Subversion projects employ them in some shape or form, but there’s often some confusion surrounding these concepts. Essentially, ‘trunk,’ ‘tags’ and ‘branch’ all refer to directories in Subversion, but they’re used to distinguish how users handle these directories. Subversion doesn’t force you to organize your project into trunk, tags and branches, but arranging your data in this conventional format allows you to access the wealth of Subversion tutorials and guidelines online – and, of course, it makes it easier to reach out to the community for help if you get stuck! In this post, we provide a quick introduction to the trunk, tags and branches conventions, alongside some practical advice for getting the most out of these conventions.


The trunk is the main line of development in a Subversion repository. It contains the main codebase and is always stable. In the early days of a project, there will be little need for branches and tags, as you will spend most of your time making changes and committing them back to the trunk of your repository.


The Subversion repository remembers every change written to it. This allows the client to read the latest version of the filesystem tree, but also to view the previous states of the filesystem. Users can tag certain revisions of the repository with more human-readable file names (e.g “release-2.0”) for easy reference. In this scenario, if you ever need to look at the source code for version 2.0 again, you can easily locate the tagged file and pull the code back out.


Branching is a line of development that exists independently of another line. Branches allow developers to work on code independently of the work going on in the trunk. Branches can be made either from:

The working copy:

  • right-click on your working project and select branch/tag.
  • specify where you want the information to go.
  • add a log message to explain why you’re creating this branch.

The repository:

  • from within the repository browser, select where you want to branch from and right-click
  • select the ‘copy-to’ command
  • specify the name of the new branch and the location where the branch should be created
  • add an optional log message to describe why you’re creating this branch

So, when should you branch? Every project is slightly different, but there are some common reasons to create a branch:

1) Concurrent development branch: When performing concurrent development, to isolate development. This is the most common reason to create a branch.
2) Release branch: To tag a project and keep track of released code. Upon completing a release, the development team create a branch and tag it with a name that is meaningful to that release (e.g “release-2.0”) This provides an identifiable record of how the released code looks.
3) Experimental branch: To test a new technology that may not necessarily become a part of the main branch. If the experiment works out, the new code can always be merged into the trunk.
4) Custom branch: When modifying the code for a customer’s particular need.

You would not normally create a branch for small changes, and do not normally branch from the tags folder, as the tag folder specifies what a release looks like at a certain point in time, and branching from that folder can lead to confusion.

Ready to get started with Subversion? Binaries of the latest Apache Subversion releases can be downloaded from the WANdisco website now.

Apache Subversion 1.7.1 Released

It’s been less than two weeks since the Apache Subversion community celebrated the release of Subversion 1.7, a major update for the Subversion project that delivered both new client tools and some long-awaited client-side performance improvements. Thanks to rapid feedback from Subversion’s early adopters and the hard work of the Subversion community, Subversion 1.7.1 is already available.

Apache Subversion 1.7.1 contains a list of important user-visible and developer-visible changes, including an FSFS sanity check to prevent corruption seen in the wild, and improvements to the performance of both ‘svn info’ and hash table sorting, and improvements to the memory usage in merge.

Other important fixes in 1.7.1 include:

  • a fix for a memory leak in ‘merge –reintegrate.
  • a fix for an invalid assertion in merge.
  • a fix for upgrading WCs containing authz-restricted dirs.
  • updated bash completion for 1.7.
  • fixed handling of directories after ‘update –set-depth=empty
  • make ‘svn ls’ continue to work with 1.0-1.3 repos.

More information on the fixes and enhancements, is available in the Changes file. This is the most complete Subversion release to date, and users are encouraged to upgrade to this release as soon as possible. As part of our commitment to the Subversion community, fully-tested, certified, open source 1.7.1 binaries can be downloaded from WANdisco now. Subversion 1.7.1 is also available through our free, uberSVN platform for Subversion.

The TortoiseSVN Windows client has also upgraded to 1.7.1, featuring fixes in both TortoiseSVN and the underlying Subversion library. TortoiseSVN 1.7.1 can also be downloaded directly from the WANdisco website.

Getting Started with Jenkins in uberSVN

WANdisco are experts on which tools add the most value for Subversion users. With the free-to-download uberSVN and uberAPPS, we have taken the hassle out of ALM by selecting the best free and paid application lifecycle management products for Apache Subversion, and offering them on a ‘one-click to purchase, one more click to install’ basis. Our uberAPPS store includes Jenkins, the number one open source continuous integration server. The Jenkins CI system allows users to manage and control the application development lifecycle, including build, documentation, testing and packaging. In uberSVN, Jenkins can add value by watching for code changes in repositories, automatically performing builds, initiating tests, notifying users, rolling changes back and forth, scheduling, monitoring and managing external, time-based cron jobs, and performing operations on remote machines.

In this post, we’ll walk you through downloading Jenkins and creating your first job, before looking at some more advanced project options, designed to give you maximum control over your Jenkins installation.

Installing Jenkins

uberSVN makes the download process as simple as possible, by offering Jenkins through its integrated ‘uberAPPS’ store. (Please note that system admin permission is required to download, install and activate Jenkins). To add Jenkins to uberSVN, simply follow these five steps:

1) Select the ‘uberAPPS’ tab from the uberSVN dashboard. This takes you to the store front, where all the available apps and services are displayed.
2) Select Jenkins. This takes you to Jenkins’ product screen, where you can browse the product description and links to relevant websites.
3) Click ‘Download Now’ and uberSVN’s updates will download Jenkins from the WANdisco servers:

4) Once installed, Jenkins is ready to deploy: just click ‘Activate!’
5) A new ‘Jenkins’ tab will appear, which leads directly to uberSVN’s integrated ‘Jenkins’ screen.

Admins can decide to either make Jenkins available to all uberSVN users (in which case the Jenkins tab will be visible to everyone who logs into the uberSVN portal) or define exactly who can access Jenkins. To limit who can access Jenkins, specify users in the Application Visibility field:

Creating Your First Job

Once you have successfully installed Jenkins, a Jenkins sub-tab will be added to the repository screen. To create your first job, simply:

1) Select the Jenkins sub-tab.
2) Click ADD to add a new job:

3) When prompted, enter a Name and Description and indicate whether you are wanting to Copy Existing Job.
4) The screen will display the Jenkins project form, pre-configured to use the selected repository. This is where you may encounter a quirk with Jenkins that causes the following error to be displayed when you set up your first job:

Unable to access http://repository url:svn: Options/repo name failed (show details)
(Maybe you need to enter credential?)

5) To get around this problem, click on the ‘enter credential’ link and enter the username and password for an account that is valid for the repository, and has read permissions.

6) If the account is valid, you will see the following confirmation message:

Authentication was successful. Information is stored in Hudson (sic) now.

7) Run through the available options for how you want the job to be set up – and hit save!

Creating Jenkins through uberSVN in this way, allows the user to easily track the jobs via the Jenkins tab in the uberSVN portal.

Advanced Options

As you can see, uberSVN is designed to make it as easy as possible to get up-and-running with Jenkins, even if you’re a first time user. But, for those with more experience, uberSVN includes plenty of advanced project options, for users who want maximum control over their Jenkins installation:

Quiet period – defines the amount of time a newly-scheduled build waits before actually being built. This is useful for collapsing multiple CVS change notification emails into one, and when a Jenkins installation is too busy with too many builds.

Retry count – specifies the amount of times Jenkins will retry when a build fails to checkout from a repository.

Block build when upstream project is building – prevents the project from building when a dependency of the specified project is in the queue, or building.

Block build when downstream project is building – prevents the project from building when a child of the specified project is in the queue, or building.

Use custom workspace – specifies the workspace location manually. This is useful in a few situations, for example when paths are hard-coded and when the code needs to be built on a particular location.

Build after other projects are built – schedules a new build for a project, when a particular project has finished building. This is useful for running an extensive test after a build is complete.

Publish JUnit test result report – Jenkins understands the JUnit test report XML format, and this option allows it to provide useful information about test results, including historical test result trends, and a web UI for viewing test reports.

Build other projects – triggers builds of specified projects once another build has been successfully completed.

Archive build artifacts – for example, distribution zip files or jar files, so they can be downloaded later.

Aggregate downstream test results – a convenient way of collecting all the test results from downstream test jobs and displaying it alongside the relevant build. This allows users to quickly see the overall test status of the given build.

Record fingerprints of files to track usage – keeps track of where/when certain files are produced and used. To use this feature, all of the involved projects (including the projects in which the file is used) must be set to record fingerprints.

Email notification – Jenkins will send out an email to the specified recipients when a certain improvement event occurs.

That gets you started with Jenkins, be sure to check back later for more help and advice on getting the most out of Jenkins and other uberAPPS.

uberSVN can be downloaded for free from

Subversion Best Practices: Repository Structure

Maintaining a Subversion repository can become a complex task, and implementing the right project layout from the very beginning is crucial. As Subversion doesn’t impose a strict file structure, users are free to tailor Subversion repositories to their project’s needs. Users can organize Subversion on a ‘one project per repository’ basis or create multiple projects within the same repository; and have considerable freedom when it comes to how they use Subversion’s trunk and branches. In this post, we’ll look at some guidelines and best practices on how to keep Subversion files, for users who are embarking on a new project in Subversion.

Multiple Projects: Single Repository vs. Multiple Repositories

In modern software development, it’s normal for teams to be working on multiple projects simultaneously. If this sounds like your organization, the first question you’ll need to answer is: should I set up a single repository for multiple projects, or create one repository per project? Although the experience will be slightly different for each project, there are some general benefits and drawbacks to each approach.

Single Repository

Single repositories are typically suited to organizations managing multiple, small projects that require cross references, cross tracking, etc.


  • there is a single location where all the code is stored, even for projects you aren’t directly involved in.
  • ability to reuse common libraries.
  • lack of duplicated maintenance (e.g only one repository needs to be backed up.)
  • the ability to move data between projects more easily, and without losing any versioning information.
  • all projects share the same repository history.
  • typically less administration – new projects can be created without creating a new repository, and without the help of sysadmin.
  • you can delete entire projects without losing the record from Subversion.


  • Subversion uses repository-global revision numbers which apply to entire trees, not to individual files. The revision number for projects will increase in accordance with the rest of the repository, even if no changes have been made to that particular project.
  • unable to use unified logging (svn log command).
  • branching can be complex when many folders and files are involved.
  • dumping/loading one huge repository can be time-consuming.

Multiple repositories

These are typically suited to multiple large unrelated projects.


  • the ability to define different access permissions, for different users.
  • each project repository will have its own revision sequence.
  • the version number is meaningful for all projects.
  • projects have a tendency to increase in size, and numerous large projects on a single repository can become difficult to maintain. It is typically easier to manage large projects with a ‘one repository per project’ approach.
  • can tailor each repository’s structure to suit a project’s unique needs. This can include branching, tagging, naming conventions, etc.


  • Subversion does not support merging code between projects in different repositories, and the transplanted code will appear in the new repository with no history. This also means you cannot perform merges if you need to temporarily maintain two versions of related code.
  • different projects have different mailing lists, which can be a problem if there’s cross-over between two related, but separate, projects.

There is also the potential to have more than one repository, and to group related projects within the same repository. This allows related projects to share data, and when new revisions are added to a repository, they are more likely to be relevant to everyone who uses the repository.

Project Layout

Once you’ve decided whether to organize your projects in a single or multiple repository structure, it’s time to plan your project layout. Putting some thought into your layout in the beginning, can help you avoid having to move files around later.

An illustration of how a Subversion Repository evolves using branching, tagging and a code trunk.

Here are some best practices for getting the most out of your project layout:

  • Project root – This is the anchoring point for a project. A repository may contain one project root, or multiple roots, but each project root contains three subdirectories: /trunk, /branches, and /tags. The use of a project root is officially recommended by the Apache Subversion project.
  • Trunk – This is where you should store current release code – only! Don’t muddy the trunk directory with revisions or release names.
  • Branches – Use these to work on significant changes, variations of code etc, without disrupting the current release code.
  • Bug fixing on a branch – Branches should be created to fix major bugs; this allows bug changes to be immediately worked on without disrupting whatever work is currently underway in the trunk/development branches.
  • “Toe in the water” branches – Branches can be used as a code “sandbox” where new technology can be tested without risking the working code. If things go right, the new code can always be merged back into the trunk.
  • Tags – Should be used as “code milestones” providing a snapshot of the code at specific points in its history.
  • Tagging bug fix / development branches – when creating a code or bug fix branch, it’s useful to create a “pre” tag, and a “post” tag after the bug fix or code change has been completed:

Ready to start a new project with Apache Subversion? Certified open source Apache Subversion binaries can be downloaded from the WANdisco website.

Branching Options for Development

Branching and merging is a contentious issue for the Subversion community, with even the most experienced Subversion users sometimes needing extra guidance on how best to manage their branches. In our latest webinar, Michael Lester, WANdisco’s Director of Training, provided an introduction to branching and merging which ranged from the basic, ‘what is a branch?’ question, to the different development models open to Subversion users, and advice on managing deleted branches.

Essentially, a branch is a line of development that exists independently of another line. Branches allow developers to work on code independently of the work going on in the trunk. No changes made within a branch are seen by people working in the trunk, or in any other branches. There’s no real limit on the number of branches that can be created, but there are some general development models for branching that Michael addressed in the webinar:

1) “Branching Nothing” Development Model

In this model, all of the development is done within the trunk. In ideal circumstances, all of the checkouts and commits will be in line, and no-one will check out the same thing at the same time, but it’s likely there will eventually be a situation where multiple people checkout the same code simultaneously, and then it becomes a race to see who can make their commit first. The second person to make their commit will receive a message alerting them that their commit has failed, and that they must update their working copy.

‘Updating the working copy’ takes the differences between what was checked out and edited, and what the other person has modified, and applies it to the working files. In the best case scenario, this is a straightforward update, but in some cases it can create a conflict situation.

The branching nothing model can create ‘update hesitation,’ where the developers are aware that performing a commit could force them to go back and deal with other peoples’ changes – a potentially time-consuming and annoying process! – which encourages them to wait until the last minute to make their commit. The branching nothing development model tends to get more complicated, the more people who are working on the same code, at the same time.

2) “Branch Everything” Development Model

With this development model, every change within a project is given its own branch; either a ‘bug branch’ or an ‘enhancement branch.’ People are assigned to work on a particular branch, and these branches are then merged into the trunk. This has a number of advantages:

  • All work is isolated. You don’t have to worry about other changes interfering with yours until the merge happens.
  • All work is scheduled. There is a defined branch for everything that needs to be worked on.
  • All work is branched from a stable trunk revision.
  • Small, independent merges mean it’s usually easier to resolve changes.

However, there are also some disadvantages to this development model:

  • Lots of branches.
  • Lots of merges.
  • A lot of overhead for some very straightforward fixes, e.g the misspelling of a word, or a column heading not being centered.

3) “Branch Big Things” Development Model

With this development model, every task is divided into one of two categories:

  • A small development effort – worked on directly in the trunk, with no branching or merging required!
  • A big development effort – tasks such as a complicated bug or enhancement are given their own branch.

This categorisation is based on:

  • Relationship to other bugs / enhancements – is the change likely to impact any other code?
  • How much testing is required? – some changes may require virtually no testing (e.g correcting a misspelt word) but other times you will literally have to do system-level testing to ensure the changes haven’t had any unforeseen negative effects.
  • How long will the bug/enhancement take?

Deleting Branches & Finding Deleted Branches

Regardless of whether you branch everything, or follow the ‘branch big things’ development model, if you’re going to branch, then at some point you’ll have to delete some of the old branches. Deleting branches is simply a matter of:

1) Go to the repo browser.
2) Right click on the branch you want to delete.
3) Select the delete command.

Remember that when you delete a branch, it gets deleted from the revision folder but not from the repository. You can always go back to an earlier revision to see how the branch looked, and have the option of exporting the code from the deleted branch, or recovering the branch and recreating it in a later revision.

To make it easier to locate a deleted branch, it is a often a good idea to write something in the log message upon deleting that branch. Another good idea, is to create a ‘deleted branch’ folder, where you can store branches that you no longer need.

Need more advice on branching and merging? The full webinar is available for replay now. Our next webinar, ‘uberSVN: Access Control Management’ will show you how to quickly setup access control for Subversion users and how to easily create repository access rules, allocate users to teams, and monitor team activities. The webinar will take place on October 27th, 2011.

POW! = Photo Of Week!

We believe the WANdisco office is a pretty cool place to work, so we thought we would give a small window into our world through POW!

POW! = Photo Of Week! We know it should really be POTW (photo of the week) but I’m sure you’ll agree ‘POW!’ sounds way better. We also agreed that having the word ‘POW’ without an exclamation mark just wasn’t right.

This is Mark, our technical writer, taking the slide down to reception. Yes you read that right, we have a slide in our building!

How to Install Subversion on Windows 7

A beginner’s guide to installing Subversion on Windows 7 using WANdisco’s easy-to-use uberSVN, which for the first time opens up the power of Subversion version control to people who are not computer boffins.

1) Check that your computer is up to the task.

  • Pentium 4 3.0 GHz or higher.
  • 1.5GB of RAM (2GB+ recommended) RAM should be split: 256MB to Apache and 1GB to Tomcat.
  • If running additional apps, such as Jenkins, 2GB of system memory should be considered a minimum, with Tomcat given no less than 1GB.
  • 200MB of disk space for uberSVN (not including space for your Subversion repository data).
  • TCP/IP networking must be configured and working.
  • Subversion itself isn’t particularly demanding, although uberSVN lets you quickly add additional applications and services, which can quickly gobble up a basic system’s resources.
  • Your computer looks up to the task? Good stuff, then it’s time to Download uberSVN.

2) Run the installer, making sure that you have admin permissions.

3) If an Open File prompt appears, click the Run button.

4) The Welcome to uberSVN Setup Wizard starts. Just click Next>.

5) Confirm where you want uberSVN to be installed. The default location works for most people.

6) Wait until all the files have been extracted. Click Next >.

7) The installation’s completed. There’s a start option; do you want uberSVN to automatically start up whenever your computer boots up? It’s a good idea to leave this ticked if you want Subversion to be available to users without you needing to start it up every time the system restarts. However, you can easily change your mind either way, later. To move on, click on the big link to go through uberSVN’s settings.

8 ) The first uberSVN setup screen (Installation Settings) will open in your browser. This screen shows you where uberSVN has been installed (Installation Directory), where uberSVN will store your repository data (Repository Storage Location) and the uberSVN key. If you don’t have a key, follow the link to get one (don’t worry, it’s free). Click the Next button to continue.

9) Time to create the Admin User’s account. Enter your full name, your email address and a username which you’ll use to login to uberSVN. Provide a password, then re-enter it. To continue, click the Next button.

10) Some technical stuff next, but don’t worry, the default values will work fine. You can come back later to change these values, especially the BASE URL. See the Tips section about how and why you should change ‘localhost’ for your computer’s actual IP number. Click the Next button to continue.

11) Final step. Woohoo! You can set uberSVN up to send out emails to users. You need an email server that will accept mail using SMTP (Simple Mail Transfer Protocol). Again, you can select ‘No’ and come back to these settings later after uberSVN is setup. Click the Next button.

12) uberSVN will now take your settings and apply them. This will take a minute or two. Time enough for a coffee, maybe? When the setup is complete you’ll be able to click on the Start using uberSVN button.

13) Starting uberSVN will open a browser window that shows a login prompt. Enter the Admin username and password that you provided in step 10, then click Login.

14) Congratulations, you just installed uberSVN. You are now running Subversion.


During installation you’ll be asked to confirm the BASE URL of your computer. By default, the installer will use the short-hand address ‘localhost’ which on a network simply points back at the local computer. However, this won’t work for anyone looking to use uberSVN from a different computer – it will point to their own computer instead of yours. The solution is to get your computer’s IP address. Here’s how:

  • Click Start
  • In the search window, enter cmd, then press the Enter key.
  • A trusty DOS style command window will open up. ‘Old School!’
  • Type in ipconfig then press the Enter key.
  • Pick out the IPv4 Address for your network card, if you have multiple network adaptors, it’s likely to be the top one. The address will have the format xx.xx.xx.xx, four numbers separated by full stops.

How to Install TortoiseSVN and Make Your First Repository Change

This is an introduction to Subversion, using WANdisco’s uberSVN and the trusty Windows client, TortoiseSVN. In fact, you can think of this tutorial as a set of TortoiseSVN water wings, aimed at developers who have been thrown into Subversion at the deep end. As well as getting TortoiseSVN installed, it’ll show you how to get your working copy in place and your first changes made to the repository.

1) Download the latest version of TortoiseSVN

2) Double click the installer file.

3) Click the Run button.

4) You’ll see the welcome screen, which will confirm the version of Tortoise that you’re about to install. Click Next >

5) Read the End-User License Agreement. If you’re happy to proceed, click the ‘I accept the terms…’ radio button and then click Next >.

6) The Custom Setup screen lets you deselect various elements of the install. Unless you are really low on disk space, it isn’t worth worrying about this. When you’re ready to continue, click Next >

7) Click Install.

8 ) Hey presto! Tortoise is now installed. Click Finish.

9) To work with a Subversion repository we first need to download a local copy (called a working copy) of either the full or part of the repository. We start by creating a directory in which we’ll store the working copy.

10) Open Windows Explorer, go to the new directory and right click within the folder space. The Explorer context menu appears, along with Subversion commands that are added with TortoiseSVN. Click on the option ‘SVN Checkout.’

  • URL Repository: This is the URL of the repository on which you want to work. This is the address of the repository, or portion of a repository for which you want to make a working copy. You can get the repository URL from the repository’s screen in uberSVN.
  • Checkout directory: This is the location on your local file system where the checkout will occur. By default it will be the location that you’re currently focused on in Explorer, however you can change it here.
  • Checkout Depth: The Checkout Depth drop-down allows you to limit what you checkout. Useful if you only want to make a change in one directory of a very large repository.
  • Revision: You can get the latest version of the repository, called ‘HEAD’ (most up-to-date version), or select a specific revision to go back to a version before particular changes.
  • When you’ve finished with these options and you’re ready to do the checkout, click OK.

11) You’ll now see the progress of the checkout. All files and folders that are included in the checkout will be logged.

12) Next, it’s time to make a change. The working copy is now in place on your computer, ready to edit and change to your heart’s desire. One of the benefits of Tortoise as a shell replacement is the fact that it can overlay repository files with status icons that tell you the current state of each file.

13) We’ll now make a change to a file. In this example the file ‘system.txt’ will be modified and saved.

14) You’ll notice that once saved, ‘system.txt’ now has a different icon overlain, showing an exclamation mark in a red circle to denote that it has been changed.

15) Having tested the change, it’s time to add it to the repository. To apply changes to the repository that you’ve made in your local copy you need to use the SVN Commit command. You can select individual files or their directories, then right click to get the context menu. On the menu, click SVN Commit….

16) You’ll be prompted for a message to associate with the changes you’ve made. It’s human nature to try to leave this blank because you’re in a hurry and can’t be bothered, but simple log messages can really help with troubleshooting problems at a later date.

17) The outcome of the commit will appear in a dialog window. If the commit was successful the repository’s revision number will increase. Click OK. That’s it, you’re working with version control.

18) Next we’ll add something new to the repository. You see, it’s not possible to commit something unless Subversion already has a record of the file you are adding. So first, right click the file and choose Add… from the Subversion commands.

19) The added elements should now appear in Explorer with the ‘added’ overlay icon. Although Subversion now knows about the file, you still need to perform a commit. So again, right click the file and choose SVN Commit… from the menu.

20) It’s always good practise to leave a note, whenever you do a commit. While Subversion gives you lots of tools for scrutinizing file changes, it’s nice to have a quick summary to look back on. To complete the commit, click OK.

21) You’ll get a log of the commit, confirming that your new files are now part of the new repository revision.

22) That’s all there is to using Subversion with the TortoiseSVN client. Probably 90% of the work you need to do is covered here. If you get stuck though, don’t forget that you can read the user guide by clicking on the Help link in the TortoiseSVN commands menu.


  • Checkout only what you need. If you include a subdirectory in the address, the checkout will ignore anything in the repository that is above the directory. This is very useful as it lets you quickly checkout a small part of a repository that might take a really long time to copy. e.g:
  • Checkout the whole repository:
  • Checkout just a directory:
  • Checkout just a file: Alas, you can’t. Subversion needs to organize working copy data using directories as its own ‘housekeeping’ data needs to live in a hidden subdirectory. There would be no opportunity to create a subdirectory if you checked out only a file. The workaround is to use the “Checkout Depth” option to checkout only directories, then perform selective updates on the things you need.