[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Subversion upgrade from 1.5 to 1.6

From: <abhinav.chandra_at_rbs.com>
Date: Fri, 25 Jun 2010 06:34:39 +0100

Hi,

We are currently using Subversion 1.5.2 and want to upgrade to Subversion 1.6.6.

Upon going through subversion documentation, we found that there can be two ways of doing this:

1. Installing a new Subversion 1.6.6 instance and simply upgrading all the repositories via the svnadmin upgrade command.
2. Creating dumps of each of the repositories from Subversion 1.5.2 instance and loading them into the newly installed Subversion 1.6.6 instance.

Can anyone please guide us which of these two options should we go for ?

The help text for 'svnadmin upgrade' command says that it "performs only the minimum amount of work needed to accomplish this while still maintaining the integrity of the repository. It does not guarantee the most optimized repository state as a dump and subsequent load would":

$/> svnadmin help upgrade
upgrade: usage: svnadmin upgrade REPOS_PATH

Upgrade the repository located at REPOS_PATH to the latest supported
schema version.

This functionality is provided as a convenience for repository
administrators who wish to make use of new Subversion functionality
without having to undertake a potentially costly full repository dump
and load operation. As such, the upgrade performs only the minimum
amount of work needed to accomplish this while still maintaining the
integrity of the repository. It does not guarantee the most optimized
repository state as a dump and subsequent load would.

But, following excerpt from Subversion Documentation (http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate) says that there is no requirement of doing dump and reload between versions 1.5.x to 1.6.x :

"As Subversion matured, there were times when changes made to the backend database schema caused compatibility issues with previous versions of the repository, so users had to dump their repository data using the previous version of Subversion and load it into a freshly created repository with the new version of Subversion.
Now, these types of schema changes haven't occurred since Subversion's 1.0 release, and the Subversion developers promise not to force users to dump and load their repositories when upgrading between minor versions (such as from 1.3 to 1.4) of Subversion."

Also, the release note for Subversion 1.6.x (http://subversion.apache.org/docs/release-notes/1.6.html) says the same:

"There is no need to dump and reload your repositories. Subversion 1.6 can read repositories created by earlier versions. To upgrade an existing installation, just install the newest libraries and binaries on top of the older ones.
Working Copy Upgrades
WARNING: if a Subversion 1.6 client encounters a pre-1.6 working copy, it will automatically upgrade the working copy format as soon as it touches it, making it unreadable by older Subversion clients. If you are using several versions of Subversion on your machine, be careful about which version you use in which working copy, to avoid accidentally upgrading a working copy. (But note that this "auto upgrade" behavior does not occur with the repositories, only working copies.)
If you accidentally upgrade a 1.5 working copy to 1.6, and wish to downgrade back to 1.5, use the change-svn-wc-format.py script. See this FAQ entry for details, and run the script with the --help option for usage instructions.
Repository Upgrades
The Subversion 1.6 server works with 1.5 and older repositories, and it will not upgrade such repositories to 1.6 unless specifically requested to via the svnadmin upgrade command. This means that some of the new 1.6 features will not become available simply by upgrading your server: you will also have to upgrade your repositories. (We decided not to auto-upgrade repositories because we didn't want 1.6 to silently make repositories unusable by 1.5 - that step should be a conscious decision on the part of the repository admin.) "

Please provide your suggestion whether we should go for dump and load of all repositories (as in option 2) or option 1 would be as good ?

Thanks and Regards,
Abhinav Chandra
RBS Global Banking & Markets
Office: +91 124 479 1752

***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312.
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorised and regulated by the Financial Services Authority. The
Royal Bank of Scotland N.V. is authorised and regulated by the
De Nederlandsche Bank and has its seat at Amsterdam, the
Netherlands, and is registered in the Commercial Register under
number 33002587. Registered Office: Gustav Mahlerlaan 10,
Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and
The Royal Bank of Scotland plc are authorised to act as agent for each
other in certain jurisdictions.
 
This e-mail message is confidential and for use by the addressee only.
If the message is received by anyone other than the addressee, please
return the message to the sender by replying to it and then delete the
message from your computer. Internet e-mails are not necessarily
secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland
N.V. including its affiliates ("RBS group") does not accept responsibility
for changes made to this message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the onward
transmission, opening or use of this message and any attachments will
not adversely affect its systems or data. No responsibility is accepted
by the RBS group in this regard and the recipient should carry out such
virus and other checks as it considers appropriate.

Visit our website at www.rbs.com

***********************************************************************************
Received on 2010-06-25 08:07:21 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.