Sherpas Blog

Subversion Tip of the Week

SVN Revert

Apache Subversion’s ‘svn revert’ command allows you to discard local changes on a file or directory and replace it with the version in the repository. This saves you the overhead of performing a fresh checkout, and is also helpful when you need to quickly resolve a conflict.

To revert the changes on a single file, run the ‘svn revert’ command followed by the file path:

svn revert (working-copy)/filename

svn revert

It’s also possible to revert all the changes within an entire directory using the –depth=infinity switch. When this switch is added, any files that have been changed within the specified directory are replaced with their repository equivalent:

svn revert –depth=infinity (working-copy)

svn revert infinity

Useful Additional Commands

  • svn status

Before discarding your local changes, you may want to review exactly which files have been altered at the working copy level by using the ‘svn status’ command:

svn status (working-copy-path)

svn status

  • svn diff

The ‘svn diff’ command prints all the changes that have been made to human-readable files within the working copy, which is useful for identifying the file(s) you want to revert. Each line is prefixed by a character representing the nature of the change:

  1. + Line was added
  2. – Line was deleted
  3. A blank space represents no change

To run ‘svn diff’ enter the following command:

svn diff (working-copy-path)

svn diff

Looking for an easy-to-use cross platform Subversion client? Claim your free 30 day trial of SmartSVN Professional by visiting:



Subversion Tip of the Week

SVN Import

There are two main options when you need to add new file(s) to your Apache Subversion project: the ‘SVN Add’ command and ‘SVN Import.’ The advantage of performing an ‘SVN Import’ is that:

  • ‘SVN Import’ communicates directly with the repository, so no working copy or checkout is required.
  • Your files are immediately committed to the repository, and are therefore available to the rest of the team.
  • Intermediate directories that don’t already exist in the repository are automatically created without the need for additional switches.

‘SVN Import’ is typically used when you have a local file tree that’s being added to your Subversion project. Run the following to add a file/file tree to your repository:

svn import -m “log message” (local file/file tree path) (repository-URL)

In this example, we’re adding the contents of the “Release2” folder to the repository, in an existing ‘branches’ directory.

svn import 1

As already mentioned, intermediate directories do not need to exist prior to running the ‘SVN Import’ command. In this example, we’re again importing the contents of ‘Release2,’ but this time we’re simultaneously creating a ‘Release2’ directory to contain the files.

svn import create new folder

If you check the repository, you’ll see a new ‘Release2’ directory has been created. The contents of your ‘Release2’ file tree are located inside.

ubersvn import

Want more advice on your Apache Subversion installation? We have a full series of SVN refcards for free download, covering hot topics such as branching and merging, and best practices. You can find out more at

Subversion Tip of the Week

Getting Help With Your Subversion Working Copy

When it comes to getting some extra help with your Apache Subversion installation, you will find plenty of documentation online and even a dedicated forum where SVN users can post their questions and answer others. However, Subversion also comes with some handy built-in commands that can show you specific information about your working copy, files, directories, and all of Subversion’s subcommands and switches. This post explains how to access all of this information from the command line.

1) SVN Help

One of the most useful features of command line Subversion is the instant access to its built-in documentation through the ‘svn help’ command. To review all of the details about a particular subcommand, run:

svn help (subcommand)

In the example below, we’ve requested information on the ‘unlock’ subcommand. The printout includes all the additional switches that can be used in conjunction with ‘svn unlock.’

svn help unlock

Alternatively, if you need to see a list of all the available subcommands, simply run ‘svn help.’

svn help

2) SVN Info

If you need more information about the paths in a particular working copy, run the ‘svn info’ command. This will display:

  • Path
  • Repository URL
  • Repository Root
  • Repository UUID
  • Current revision number
  • Node Kind
  • Schedule
  • Information on the last change that occurred (author, revision number, date)

svn info

3) SVN Status

This command prints the status of your files and directories in your local working copy:

svn status (working-copy-path)

svn status

Want more advice on your Apache Subversion installation? We have a full series of SVN refcards for free download, covering hot topics such as branching and merging, and best practices. You can find out more at


Subversion Tip of the Week

Deleting a Branch

When something is deleted from Apache Subversion, it only disappears from the revision where it was deleted and all subsequent revisions. Deleting branches in Subversion has no effect on repository size, as it still exists in all previous revisions and can be viewed or recovered at any time. So, the question is why would you ever delete a branch?

1) House-keeping – regularly deleting branches reduces the clutter in the branches directory, and makes browsing the repository less confusing. When all abandoned branches are routinely deleted, a quick glance at the branches directory can tell you which branches are still active.

2) Following a merge – in some situations where you’ve finished working on a branch and merged the changes into the trunk, the branch may become completely redundant and you should consider deleting the branch to reduce clutter in the repository.

3) Following reintegration – the ‘–reintegrate’ command allows merging from a branch to the trunk, by replicating only the changes that are unique to that branch. A ‘–reintegrate’ merge uses Subversion’s merge-tracking features to calculate the correct revision ranges to use, and checks to ensure the branch is truly up-to-date with the latest changes in the trunk. These checks ensure the reintegration will not override work other team members have committed to the trunk.

Once a ‘–reintegration’ merge has been performed, the branch shouldn’t be used for development as any future reintegration will be interpreted as a trunk change by Subversion’s merge tracking. This will trigger an attempt to merge the branch-to-trunk merge back into the branch. To avoid this, the reintegrated branch should be deleted.

How to Delete a Branch

To delete a branch, run the ‘svn delete’ command alongside the URL of the branch and an appropriate log message. In this example, we are deleting the ‘bug fix branch.’

delete branch

Subversion Tip of the Week

Polling Subversion with Jenkins

There are many advantages Jenkins can offer Apache Subversion users, one of which is the option of automatically polling Subversion repositories for changes, and creating a new build whenever changes are detected. In this week’s tip, we’ll show you how to configure Jenkins to automatically poll an uberSVN repository.

(Note, this tutorial requires Jenkins to be installed in uberSVN. See Getting Started with Jenkins in uberSVN for a step-by-step guide to getting Jenkins up and running.)

1. Open the ‘Jenkins’ tab and select the ‘New Job’ option from the left-hand menu.

2. Enter a Name for your job and indicate whether you are wanting to Copy Existing Job. Click ‘Ok.’

3. You will be taken to the ‘Configure’ screen. Enter a description for your job and select ‘Subversion’ as the source code management option. You will then be asked to enter the URL of the repository you wish to link the job to.

4. Under ‘Build Triggers’ select ‘Poll SCM.’ In the ‘Schedule’ text box, enter how often you want Jenkins to poll the repository. You can specify the frequency that Jenkins will poll Subversion, using the following format:

MINUTE: Minutes within the hour (0-59)
HOUR: The hour of the day (0-23)
DOM: The day of the month (1-31)
MONTH: The month (1-12)
DOW: The day of the week (0-7) where 0 and 7 are Sunday.

@annually, @yearly, @monthly, @weekly, @daily, @midnight, and @hourly are also supported.

5. Click ‘Save’ and Jenkins will begin automatically polling your Subversion repository at the specified intervals.

Not yet started with uberSVN? It’s free to download and free to use. Visit now to get started.

Subversion Tip of the Week

Creating a Working Copy in Apache Subversion

The first step to creating an Apache Subversion working copy on your local machine, is to create a repository. This is made easy with uberSVN, the free, open ALM platform.

Create Your Repository

1) In uberSVN, open the ‘Repositories’ tab. Click the ‘Add’ button.

2) Enter a name and location for your repo – this is the directory name for the repository, and will appear the end of the URL. Click ‘Next.’

3) Make sure the ‘Create new repository’ and ‘Create trunk, branches and tags directories’ checkboxes are ticked. Click ‘Done.’

4) uberSVN will automatically open a ‘Permissions’ tab, where you can configure your access rules. Permissions can either be controlled by uberSVN or through an external Authorization file.

Your repository is now ready! It can be accessed through the ‘Repositories’ tab. Be sure to make a note of the repository URL as you’ll be using it to create your working copy.

Entering Commands

In Apache Subversion, commands are entered via the terminal window. In Windows, this can be opened by pressing the “Windows key” and “r.” In the ‘Run’ dialog box enter “cmd” and click “Ok.” This will open the terminal window.

Checkout a Working Copy

Now it’s time to checkout a working copy. Enter the ‘svn checkout’ command followed by the URL of your repository and the location where you wish to create your working copy.

svn checkout (URL) (location)

In this example, we’re creating a working copy on the desktop, in a file called ‘Repo’:

You have now successfully created your first working copy!

Subversion Tip of the Week

Apache Subversion: Basic Workcycle

In Apache Subversion, the basic workcycle follows the ‘checkout-edit-update-commit’ format.

A ‘Checkout’ is the process of pulling all the files from your repository onto your local machine, where it becomes known as a ‘working copy.’ You can then work on these files in isolation, before sharing your work with the rest of the team by ‘committing’ back to the repository.

In this week’s tip, we’ll provide a handy introduction to this basic workcycle.


To checkout a working copy, run the ‘svn checkout’ command, followed by the URL of your repository and the location where you wish to create the working copy.

In this example, we’re creating a working copy on the desktop, in a file called ‘Repo’:

Tip, if you’re using the free uberSVN platform, you can easily find out your repository’s URL by opening the ‘Repositories’ tab.

You can now edit the files and folders in your working copy.


You may be ready to share your changes with the rest of your team, but it’s good practice to perform an SVN update first. This will pull any changes your colleagues may have already committed, into your working copy, ensuring your changes fit with the most up-to-date version of the project.

To perform an update, run the ‘svn update’ command, followed by the location of your working copy.

svn update (working copy location)


Let’s assume any changes your team committed are compatible with your changes, and go ahead with the commit. When performing a commit, you should leave a log message and include as much information as possible, as this can be an invaluable source of information if you ever need to revisit this revision. When performing a commit, the log message is entered in the “–m” format (for example, -m “added ReadMe file.”)

The commit itself is performed using the ‘svn commit’ command, followed the log message and the location of the working copy.

svn commit -m “log message” (working copy location)

In this example, we are performing a commit with the log message “added Admin Guide text.”

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. We’re currently running a very special early bird offer: register now using the ‘earlybird’ code to get a 25% discount (note, the early bird offer ends 10th August, so you better be quick!)

Subversion MultiSite Enables Agility For the Distributed Enterprise

The Agile methodology has become a wildly popular approach for software development with close to 50% of development teams using at least some agile techniques based on different surveys. The responsibility of an agile team is to deliver value in the software they are creating and meet the criteria or objectives that determine success for the project and a common set of development “best practices” have arisen that are crossdisciplinary. Adopting these best practices can be especially challenging for collaborating agile teams that are distributed or have distributed members.

The Agile principles state that successive short development cycles, popularly referred to as rapid iterations, be used to develop software quickly in little bits (pun ;)) at a time. Different methodologies have arisen from the Agile principles like Scrum, XP, TDD, Crystal and others which define activities and process for agile teams. The process gets into the specific details for each discipline but agile teams enjoy a great amount of freedom for self organization as well as self definition which as a result teams may borrow one aspect of another methodology to apply to their own agile approach. Popular examples of this are the XP User Story or and the Scrum Backlog.

The common principles mixed together with the common practice of borrowing the best aspects of each discipline has helped popularize a set of software development best practices. These are practices which are good for any software development team but the popularity and nature of agile software development has led these practices to be commonly associated with agile specifically. Here is a list of the more common agile best practices:

  • Rapid Iteration
  • Continuous Integration
  • Parallel Development
  • Frequent Commits
  • Automated Testing
  • Code Review
  • Refactoring

If you are an enterprise considering a large scale adoption of agile software development practices then there are a number of challenges that you may be facing. Scaling Scrum is well documented in Ken Schwabers book “The Enterprise and Scrum” and he has special sections dedicated to the problems of distributed teams, distributed members and the scarce skills problem (eg: one DBA shared by many teams). Ken handles the issues associated with the organization and daily routine for Agile Scrum adopters, but what about the technical challenges especially those associated with the best practices I listed? This is an area where the value added services offered by WANdisco enter the conversation.

Using Subversion Multisite and Apache Subversion will enable teams to fully adopt an Agile practice like Scrum on an enterprise scale, especially where distributed teams or members are concerned. Here is how.

  1. Subversion Multisite instantly synchronizes development changes between locations. This means that distributed teams always work against a local source code repository, without which frequent commits, continuous integration, code reviews and parallel development might not be possible at all or at best will be severely hindered if users are required to connect across the internet to access the source code repository (for read or write activities)
  2. Multisite also supports local clustering option, an enterprise that sets up two or three load balanced Subversion servers will better handle the increased traffic from frequent commits and especially from continuous integration where automated tests and builds are being performed continuously and using up a lot of server resources.
  3. Multisite leads to improved team communication, imagine a tester working in Los Angeles getting the latest build locally almost immediately after a task is committed in New York (again locally). When each site has access to a complete replicated copy of the source code repository many things are possible and the usual downtime related to downloading a new build off a remote server or uploading a set of new changes to a remote server can be entirely eliminated.

An enterprise that is considering or has already adopted agile practices will also want to adopt the software best practices. Given the nature of agile development and rapid iterations adopting these best practices are critical and with Subversion Multisite many of the technical challenges facing distributed teams can be easily solved. There are of course other benefits to Multisite such as built in disaster recovery, guaranteed uptime that will also interest any enterprise and the value offered to Agile teams will be indispensable especially as the Agile usage scales upwards.

Intro to Subversion Access Control 4.1

Big plans are brewing at WANdisco for 2012, and one project that has just been completed, is Subversion Access Control 4.1.

Access Control 4.1 includes a revamped user interface. The new look makes it easier for users to navigate through the security features offered by Access Control and setup new rules and permissions for Subversion repositories and paths.

The ‘Group’ concept has been replaced with “Teams’ and a new feature has been added to allow the designation of “Team Leader” who is then granted some administrator privileges. Specifically, the Team Leader is able to setup user access rules to a pre-defined repository path (or paths).

We are calling this new feature Delegated Admin since it allows granting of some administrator privileges to users. The context of how this feature could be used might be best described in terms of business units for an enterprise corporation. Consider the following scenario.

A company has 100 Apache Subversion users split into 10 teams, each associated with a separate BU, each team has its own Subversion repository. In the past, Access Control admin can go in and setup repository security rules that applies to all 100 users and repositories. With delegated admin the Access Control administration can create 10 new Teams and assign a Team Leader to each one, specifying the Repository that team should have access to. From there, the Team Leader can log into the system, add/remove the users for the team, and setup multiple rules needed to properly manage those Subversion assets.

Effectively what delegated admin does is allow Team Leaders, people in charge of their respective Business Units, to define and configure their own team rules. Access Control supports the concept of nested-teams which is called Sub-Teams (see screenshot) and this would even allow you to further organize teams from larger sections into multiple sub-sections (eg: West Coast Branch –> Plugins Team; West Coast Branch –> Application Team) and designate a team leader at each level to manage users and rules.

The role of the Access Control administrator now is to simply define Team Leaders and the resources which they can direct access over. Once defined the Team Leader can only create rules that affect their resources meaning the West Coast Branch won’t be able to setup access rules for the East Coast Branch’s repositories and vice-versa.

The ability to delegate some administrator functionality to Team Leaders, and in the context of specific Subversion paths and repositories, is a powerful new feature that will empower enterprise organizations and save time and money. Team Leaders are able to set access restrictions based on the need and requirements of their given team or business unit and no longer have to rely on a single administrator to do that for them.

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.