Tag Archive for 'merge'

Page 2 of 3

Getting More out of Version Control with SmartSVN

In our previous SmartSVN posts, we covered essential functionality to get you off to a flying start with this cross-platform graphical client for Apache Subversion. In this post, we cover some more advanced options, including performing a reverse merge, reverting local changes and resolving any conflicts that occur when you try to perform a commit with SmartSVN.

Didn’t catch our intro to SmartSVN series? Get up to speed with the following links:

Reverse Merge

As Subversion remembers every change that’s committed to the repository, it’s possible to revert to previous revisions of your project. This is useful if you introduce a code-breaking feature in revision 15, and need to revert to a revision before it all went wrong. This is achieved by performing a ‘reverse merge’ i.e merging the changes in your current revision, to an earlier revision.

To perform a reverse merge with SmartSVN:

1) Select the ‘Merge’ item from the ‘Modify’ menu.

2) In the Merge dialog, enter the revision number you wish to roll back to.

 

 

 

 

 

 

 

If you need more information about the different revisions, click the ‘Select…’ button next to the ‘Revision Range’ textbox. The subsequent dialog displays the different revisions, alongside the commit message, time, author and path data for each revision. Note, the green arrows indicate revisions not yet merged.

 

 

 

 

 

 

 

3) Ensure the ‘Reverse merge’ checkbox is selected and finally, click ‘Merge.’

4) Remember to commit your changes to the repository, to make this reverse merge permanent!

Alternatively, right-click the revision you wish to reverse-merge in the Transactions tool window and select “Rollback.”

Revert

Revert overwrites any local changes made to the working copy, with the file content held in the repository. Note, this command should be used with caution: a revert effectively deletes all the changes made since your last commit, and once they are gone there is no way to recover them.

To perform a revert with SmartSVN, right-click on the file/directory you wish to revert, and select the ‘Revert’ option from the drop-down menu  (alternatively, select the ‘revert’ button from the toolbar.)

 

 

 

 

 

 

 

SmartSVN will ask you to confirm the revert. Select the ‘Revert’ button to go ahead and remove all your local changes.

 

 

 

 

Relocate

At some point during your project’s lifecycle, your repository may change location and therefore get a new URL. This can be solved by deleting your working copy and performing a checkout from the new repository location, but there is a quicker way to solve this problem: the ‘Relocate’ command can be used to rewrite all the URLs associated with the files and folders in your working copy, with the new URLs. This allows you to continue using your current working copy and, of course, to successfully commit all your hard work back to the repository.

1) Open the ‘Modify’ menu and select ‘Relocate…’

2) The ‘Relocate’ dialog displays the URL of the selected directory. In the ‘To URL’ option, specify the replacement URL.

 

 

 

 

 

 

3) Select ‘Relocate’ to change the repository for your directory.

Note, this operation should be used with caution, as if used incorrectly it can corrupt your working copy. The ‘Relocate’ command should not be used to:

  • move to a different Subversion repository.
  • switch to a different branch or directory within the same repository.

Resolving Conflicts

When you are performing a commit in Apache Subversion, you may occasionally encounter the dreaded Subversion conflict, and your commit will fail. Thankfully, SmartSVN comes with a ‘conflict solver’ to help resolve these conflicts when they do occur. To access this conflict solver, open the ‘Query’ menu and select ‘Conflict solver.’

 

 

 

 

 

 

 

 

 

 

In the ‘Mark Resolved’ dialog, you can opt to:

  • Leave the file/directory as it is.
  • Take the version in the working copy, as it was before the update or merge was performed.
  • Take the new version – the pristine copy after the update or merge was performed.
  • Take the old version – the pristine copy before the update or merge was performed.
Select the appropriate checkbox and select ‘Ok.’ The conflict should now be resolved, and you can commit your changes to the repository to make them permanent.
Set a Property
‘Properties’ in Subversion are useful for associating metadata with the files placed under version control. To set a property for your Subversion files or directories using SmartSVN, open the ‘Properties’ menu and click ‘Select or delete Property….’
Use the drop-down ‘Property’ menu to select the desired Subversion internal property. The default properties are:
  • svn:eol-style – makes the client convert line-endings in text files. This property is used when the working copy is required in a specific EOL style.
  • svn:executable – makes files on Unix-hosted working copies executable.
  • svn:externals – a multi-line value defined on a directory that allows parts of other repositories to be automatically checked out.
  • svn:ignore – a list of unversioned filename patterns that should be ignored by ‘svn status’ and other subcommands.
  • svn:keywords – Subversion has the ability to substitute keywords into the contents of a file itself when changes are made. Keywords are useful for automatically maintaining information (such as author, revision number, etc) that would be too time-consuming to keep changing by hand.
  • svn:mergeinfo – this property is used to track merge data and is automatically maintained by the ‘SVN merge’ command.
  • svn:mime-type – indicates the file’s MIME type and allows the client to decide if contextual merging is safe during updates. Note, this property affects the handling of diffs and merging.
  • svn:needs-lock – tells the client that files should be checked out with permissions set to read-only. This is designed to be used in conjunction with the ‘SVN Lock’ command, to remind the developer to obtain a lock before beginning work on a file. This saves the developer from spending time modifying a file and then discovering it’s locked when it’s time to commit.

Select a value for your property (if applicable) and hit the ‘Ok’ button to set the new property.

Visit http://smartsvn.com/ to claim your free download of SmartSVN Foundation.

New Subversion Live Session: Beyond Scrum

Subversion Live 2012, the global conference series for the Subversion community,  is fast approaching, and today we’re excited to bring you news of a brand new Subversion Live session. Andy Singleton, Founder and CEO of Assembla will be presenting ‘Beyond Scrum: The Move to Scalable Agile with Continuous Delivery,’ joining our list of exciting speakers, which includes:

  • Greg Stein – Vice President of Subversion and former ASF Chairman
  • Hyrum Wright – Software Engineer at Google
  • Stefan Fuhrmann – TortoiseSVN contributor since 2003 and committer to the Subversion project since 2010
  • Julian Foad – lead developer for enhancements to Subversion’s merge capabilities at WANdisco
  • Philip Martin – part of the team that developed the first version of Subversion

Andy Singleton’s session will cover how the new and improved code merge system in the upcoming Subversion 1.8 release will facilitate the continuous delivery process for the first time, transforming the possibilities for scalable and agile development processes for the enterprise.

In addition to Andy’s cutting-edge SVN 1.8-focused session, Subversion Live will cover a wide range of topics:

  • Merge & Performance Improvements
  • Hook Scripts
  • Branching & Merging Best Practices
  • Best Practices for Large Subversion Deployments
  • ……and more!

Taking place in San Francisco (October 10th and 11th) Greenwich, CT (October 16th and 17th) and London (October 23rd and 24th) Subversion Live is a two day series of conferences especially for the Apache Subversion community. If you haven’t already registered, there’s still time to get your tickets, or learn more about this exciting event.

Merging in Subversion: Merge a Range of Revisions

Along with branching, merging is the issue that regularly causes Apache Subversion users the most confusion – but merging needn’t be complicated! In this post, we’ll show you how to successfully perform a merge in less than ten steps, using TortoiseSVN’s ‘merge a range of revisions’ option.

Tip. Two common scenarios where this type of merge comes in handy are sync’ing a development branch by applying all the latest changes from its ‘parent’ branch; and cherry-picking specific changes to add to your release branch.

To merge a range of revisions:

1) Right-click on the file you wish to merge and open the ‘TortoiseSVN’ menu.

2) Select ‘Merge’ from TortoiseSVN’s sub-menu.

 

 

 

 

 

 

 

 

3) Select the ‘Merge a Range of Revisions’ option.

 

 

 

 

 

 

 

 

 

4) In the ‘Merge’ dialog, select the desired URL using the “….” button.

5) Either specify the revision numbers you wish to merge, or leave the revision range blank to merge all outstanding changes from the specified source.

 

 

 

 

 

 

 

 

 

6) Once you have entered all the relevant information, click ‘Next.’

7) TortoiseSVN will open the ‘Merge options’ dialog. In most instances, the default settings can be used.

8) Select ‘Merge’ to perform your merge!

Need more info on branching and merging in Subversion? This year’s Subversion Live series of conferences features a session dedicated to Branching and Merging Best Practices. Visit http://www.wandisco.com/svn-live-2012 to find out more.

Getting More Out of Version Control

So, you’ve downloaded Apache Subversion and have mastered the standard workflow – but this is just the start of what the world’s most popular version control system has to offer! In this post, we’ll dig a little deeper into Subversion and provide an overview of five features that can help you get even more out of version control, including discovering who is responsible for a specific change, and reverting to a previous version of your project.

1. Hook Scripts

Hook scripts are essentially programs that are triggered by a specific repository event. Usually, hook scripts are server side, but it’s also possible to run client side hook scripts. Hook scripts can be configured to perform the following tasks:

    • Reporting on events (e.g emailing alerts when a commit occurs.)
    • Testing for a pre-condition before allowing a commit (e.g checking a commit is accompanied by a log message)
    • Blocking certain actions (e.g blocking a commit that contains multi-gigabyte files)

 

The hooks subdirectory is automatically created along with each new repository. By default, the hook files are saved as non-executable templates (.tmpl) To make changes to these files, you simply open them as text-based documents, enter the new text, and save the file in a new format. This format is different for each operating system, for example, in Windows, the format can be either .exe or .bat.

Need some more help getting started with hook scripts? Our ‘Introduction to Subversion Hook Scripts on Windows’ has a handy example of a pre-commit hook.

2. SVN Blame

Sometimes, you just need someone to blame! Subversion’s ‘blame’ command does exactly this: it displays each line of a particular file, along with who changed each line, and in which revision it was changed. This is obviously useful for pin-pointing who is responsible for bugs and broken code, but it can also be useful for finding out who you need to contact for more information about a particular part of your code.

To find out who is to blame for a particular change, right-click on the file in question and select ‘Blame’ from the TortoiseSVN menu.

In the TortoiseSVN dialog, select the revisions you wish to review, and click ‘Ok.’

This will bring up the TortoiseBlame dialog, where you can see the changes that were made to the file in each revision, and who is responsible for each change.

For more information on a particular revision, hover over that revision and a tooltip will appear displaying the revision’s log message.

3. SVN:Ignore

Sometimes, there will be files in your working copy that don’t need to be placed under version control (you own notes, or a To Do checklist, for example) In these instances, Subversion’s ‘Ignore’ property can be used. Simply create/drag-and-drop the new file into your working copy, right-click to bring up the ‘TortoiseSVN’ sub-menu, select ‘Add to ignore list’ and select the file you wish to ignore.

This file will then be added to the ‘ignore’ list, and will not be accidentally committed back to the repository when you perform an ‘SVN Commit.’

4. Reverse Merge

Subversion remembers every change that’s made to its files and directories; a potential life-saver if you introduce a code-breaking feature in revision 12, and need to revert to a revision before it all went wrong. Recovering previous revisions in Subversion, is simply a matter of performing a reverse merge i.e merging the changes in your current revision, to an earlier revision. To perform a reverse merge with TortoiseSVN:

1) Select ‘Merge’ from the TortoiseSVN menu.
2) Select the ‘Merge a range of revisions’ option.
3) Select the revision you wish to revert to. Ensure the ‘Reverse merge’ option is selected.

4) The following dialog will present you with a number of options for merging – in most instances the default settings can be used. Click ‘Merge’ and Subversion will roll back to revision 11. Note, that the reverse merge only affects your working copy, so you must perform an ‘SVN Commit’ to commit your changes back to the repository.

5. Revert Command

Less drastic than a reverse merge, the revert command overwrites any local changes made to the working copy, with the code held in the repository, including any property changes and any scheduling operations that may have been set on the working copy. However, this command should be used with care: the revert command replaces all the changes made since your last commit, and once they are gone there is no way to recover them.

Need more help with your Apache Subversion installation? Every Monday, we’ll be publishing a new Tip of the Week at our blog, so keep checking back every week for all the latest tips!

Getting Started with Apache Subversion

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

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

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

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

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

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

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

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

Subversion Tip of the Week

Branching and Merging Best Practices

For those unfamiliar with version control, branching and merging in Apache Subversion can be a daunting prospect. But when used correctly, branching and merging can be one of the most powerful tools at your disposal. Here are some tips for avoiding merge hell – and those dreaded conflicts!

  • Isolate the merge – when performing a merge, do not add any additional planned development before performing the merge. This will make it difficult to distinguish where changes originated, and can cause major headaches if the team decides to roll back to previous revisions.
  • Use log messages – leave as much information as possible in your log messages (e.g what changes were made, why, and by whom, etc.) Log messages can be an invaluable source of information, if you need to revisit a particular revision at a later date. TortoiseSVN comes with functionality for ensuring that all team members leave appropriate log messages, including ‘Properties’ that are specific to TortoiseSVN. In this example, we’ll cover the ‘tsvn:logminsize’ property:

1) Select the properties option from the TortoiseSVN menu; this will bring up the properties dialog. Select ‘New’ property and click ‘Log sizes.’

2) You can now set the minimum number of characters for a commit message. TortoiseSVN will then block any commits with a log message shorter than the characters specified.

  • Use branches for new features and major bugs – this allows new features/bugs to be worked on immediately, regardless of the work currently underway in the trunk, or in neighbouring branches.
  • Delete unwanted branches – branches that are no longer required should be deleted. Note, deleting branches will have no effect on repository size, as the item will only be removed from the revision in question, and all subsequent revisions. It will still exist in all previous revisions, and can be viewed or recovered at any time.
  • Merge on logical checkpoints – in most cases, it makes sense to merge when the ‘from’ part of the merge (i.e the branch you’ve been working on) has reached the level of quality where changes are testable and compilable. Do not merge anytime an experimental new change has been made to the branch.
  • Merge soon – fix conflicts as soon as possible. The quicker you resolve conflicts and commit those changes back to the repository, the sooner the rest of your team can take your changes into account when working on their own part of the development effort.
  • If confused, start over – if you make any errors (for example, you’ve merged the wrong working folder) you can always start over. Simply right-click on your working copy and select ‘Revert’ to discard all local changes.

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.

WANdisco Releases Subversion ‘Branching and Merging’ Refcards

Branching and merging can be a pain-point for Apache Subversion users but when used correctly, they become an invaluable tool for getting the most out of version control. Not sure where to start with your branching and merging strategy? Our brand new refcards have all the info you need to get to grips with branching and merging.

‘Introduction to Merging in Apache Subversion’

Merging doesn’t need to be frightening! ‘Introduction to Merging in Apache Subversion’ starts with the basic question of ‘what is merging,’ before showing you how to perform the different types of merges, including reverse merges, and finally sharing some best practices to help you avoid merge hell.

This refcard covers:

  • What is ‘Merging’?
  • How to Merge in Subversion:
  • – Merge a Range of Revisions
    – Reintegrate a Branch
    – Merge Two Different Trees

  • Reverse Merge
  • Merging Feature Branches
  • Merging Best Practices

‘Introduction to Branching in Apache Subversion’

Introduction to Branching in Apache Subversion’ covers the essential know-how you need to get started with branching in Subversion, including:

  • What is a Branch?
  • How to Create a Branch
  • Identifying Branches
  • Deleting Branches

We’ll be adding more refcards over the coming weeks, so keep checking back for even more free training content. We also run frequent free webinars for the Apache Subversion community, more info is available at the Free Training Webinars page.

Deleting Branches in Subversion

In Apache Subversion, it’s easy to create new branches to the point where they become confusing. To simplify things, branches can be typically divided into two categories:

Permanent – you may want to store certain folders or projects in permanent branches, e.g copies of released code stored in tagged branches.

Temporary – can be used to test new technology or experiment with new features. Temporary branches should have a defined lifetime, and at the end of that lifetime they should be deleted. It is good practice to label a branch as temporary in the accompanying log message, and to note who is responsible for deleting that branch.

To delete a branch, simply:

  • Select the branch you wish to delete.
  • Right-click and select the ‘delete’ command.

There are several reasons why you might delete a branch:

1) House-keeping – regularly deleting branches helps to reduce the clutter in the branches directory, and to avoid confusion for anyone browsing the repository, who might expect to find ongoing development in abandoned branches. When all abandoned branches are routinely deleted, a glance at the branches directory can tell you which branches are still active.
2) Following a merge – when you’ve finished all the work in a branch and merged the changes back to the trunk, the branch becomes completely redundant and can be deleted.
3) Following reintegration – the ‘–reintegrate’ command option allows Subversion to merge from a branch to the trunk, by replicating only the changes that are unique to the branch. Subversion achieves this by comparing the latest trunk with the latest branch, and applying the resulting difference to the trunk. This is useful in a number of situations, including when all the changes made within the trunk have been ported to the branch, so the only difference is the branch changes. 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 overwrite 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, and it will attempt to merge the branch-to-trunk merge back into the branch. The reintegrated branch should therefore be deleted, and if you wish to continue working on the branch, you should re-create it from the trunk.

Recovering Deleted Branches

Deleting branches in Subversion does not completely remove them from the repository; it just removes them from the HEAD revision. You can always go back to an earlier revision to view and recapture the branch, or the files that were in that branch. Useful commands for revisiting deleted branches, include:

  • svn log –verbose – run this in the directory that used to contain the deleted item. –verbose displays a list of all the changed items in each revision, allowing you to locate the exact revision where you deleted the desired file or directory.
  • svn merge -r – can be used to roll back a change that has already been committed. ‘svn merge -r’ merges the changes from your current revision back to a revision with the changes you wish to revert to. Rolling back a change is like any other svn merge operation, so ‘svn status’ and ‘svn diff’ should be employed to approve the changes. Since the merge happens at the local working copy level, you need to use ‘svn commit’ to send the final version to the repository.
  • svn checkout –revision (number) – checks out a particular deleted branch.
  • svn switch – updates the working copy to a different URL, typically one that shares a common ancestor with the current working copy.
  • svn revert filename – rolls back local changes, on the local working copy only.

Alternatives to Deleting

If you do not wish to delete branches, there are some alternatives commonly employed by developers:

  • create an ‘inactive’ folder and move your unneeded branches to that folder.
  • rename the branches to show they are inactive.

Introduction to Apache Subversion

What is Apache Subversion?

Subversion is an Apache-licensed, open source software versioning and version control system that can track changes to files, folders and directories. It can also be used to recover previous versions of data, and examine the history of how a particular dataset has changed. Subversion can operate across networks, encouraging collaboration by allowing team members at various locations to work on the same set of data. Subversion can be used to manage any collection of files – web pages, binaries, documentation – not just source code!

Downloading and Installing Apache Subversion

Certified open source Apache Subversion binaries are available to download from http://www.wandisco.com/subversion/download

To install, open the file to launch the setup wizard and follow the onscreen instructions to define which components you wish to install, and the install location. Enter the name of your server, the host port, and define the repository and repository location prefix – and hit install.

Alternatively, uberSVN makes Subversion easy and intuitive to use, and is free to download and free to use.

Creating your first repository

Once Subversion is installed, the first thing you need to do is create a repository. To create your first repository, open the command line, change the current directory to where you want to create your repository, and run the ‘svnadmin’ command:

svnadmin create {directory name}

Checking out a Project

To start working on your project, you must check out a working copy of the repository. This is achieved with the ‘checkout’ command:

svn checkout file {file location}

Commit Your Changes

Once you’ve made some changes to your working copy, you’ll want to push your changes to the server. Perform an “svn update” and an “svn diff” to test your changes, and resolve any warnings raised by Subversion, before committing. Once you’ve finished checking your modifications, and are ready to store the new revision in the repository, run the ‘commit’ command:

svn commit {path}

Get other people’s changes

When someone else performs a commit to the repository, you’ll need to pull those changes into your working copy, to ensure the latest trunk changes are compatible with what you’re doing in your working copy. Changes can be pulled into your working copy with the update command:

svn update {file name}
or
svn update {directory name}

Adding Files to a Project

Now you know how to checkout a working copy and commit changes back to the repository – but as you continue to develop your working copy, you may wish to add some new files to your project. When adding new files to Subversion, you need to tell the Subversion server about the files with the following command:

svn add {file name}
or
svn add {directory name}

Note that the new files won’t appear in the repository until you perform an ‘svn commit’ and send them to the repository.

Deleting Files from a Project

If at some point you want to remove these files from Subversion, run the delete command:

svn delete {file name}
or
svn delete {directory name}

Again, you must perform a commit before the file is deleted from the repository. You can also run ‘svn list’ to confirm that the file was successfully deleted from the repository.

And if you get stuck…..

The ‘svn –help’ function provides a summary of available commands or, for more information on a particular command, use:

svn help {command}

Other useful commands

  • svn status {path} – prints the status of working copy files and directories.
  • svn diff – display the differences between two revisions.
  • svn merge – applies the differences between two sources to a working copy path.
  • svn move SRC DST – think of this as ‘svn copy’ that automatically deletes the source file. This command moves a file or directory in your working copy, or in the repository. Note that Subversion does not support cross-repository moving, so it is impossible to move files across repositories with this command.
  • svn list – allows you to view the content of the Subversion repository, without having to download a working copy.
  • svn log – Subversion remembers every change made to your files and directories. This command displays the commit log messages. By default, it will show the information for the current working directory of your working copy. Alternatively, different paths can be specified.

Need more info?

On June 14th, 2012 we will be hosting a free ‘Introduction to Subversion’ webinar. This course is intended as a primer for new users or people who are thinking of making the jump to Subversion, and will cover the following topics:

  • Repository basics – creating and organizing
  • Checkouts, working folders, editing files and checkins
  • Reporting on changes
  • Simple branching
  • Simple merging

This webinar is free to attend, but places are limited so register now to avoid disappointment.

Subversion Tip of the Week

How to Reintegrate a Branch

TortoiseSVN’s ‘Merge’ functionality is essential for projects that maintain separate lines of development. The ‘Reintegrate a Branch’ merge option is useful when all the changes of a branch need to be merged to the trunk.

1) To get started, right-click on the folder where you wish to perform the merge, and select the ‘Merge’ option from the TortoiseSVN sub-menu.

2) Select the ‘Reintegrate branch’ option from the Merge dialog. Click ‘Next.’

3) Select the URL from where you wish to reintegrate.

4) This page lets you specify some advanced options, although most of the time, you can just use the default settings. Click ‘Merge.’

5) You will see the following message, informing you that your merge has been successful!

Our Support Engineers are the Sherpas of Source Control Management! Just as traditional Sherpas use their deep knowledge of local terrain to assist mountain climbers in reaching the highest peaks and avoiding pitfalls along the way, WANdisco’s Subversion Sherpas use their extensive experience to guide customers away from problems and enable them to get the most out of Subversion. Our ‘Team Sherpa’ consists of highly skilled support engineers and core Subversion developers who have been working on the Subversion project since it began, and are also uniquely positioned to help you migrate to the latest and greatest releases of SVN. You can hire one of our Subversion Sherpas today, by visiting http://www.wandisco.com/subversion/support