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

upgrade from 1.3 to 1.5 - if possible should include a dump & load?

From: Steve Whitson <steven.whitson_at_gmail.com>
Date: Wed, 10 Sep 2008 09:04:04 -0500

I'm planing on upgrading from 1.3.1 to 1.5.2 in the near future. I've
worked with the svnadmin upgrade sub-command as well as the
svn-populate-node-origins-index tool w/in 1.5.2, along with the need for
both, and performed some migration-upgrades to another system-location
(using svn switch --relocate). The process seems fairly simple.

My two questions wrt 1.4 are:
1. to get the benefits of 1.4 with regard to repository size, must I
dump and load my repositories?
2. to get the benefits of smaller/faster network traffic must I dump
and load my repositories?

I ask due to what I found in the 1.4 release notes:
/In Subversion 1.4, the svndiff format has been improved to use much
less disk space --- up to 50% less on plain text files in some cases.
Thus, if you choose to dump and reload your repository, the new
repository should be noticeably smaller on disk. (Make sure to svnadmin
create the new repository using svnadmin 1.4.) Additionally, if a client
and server are both version 1.4 , then network traffic becomes smaller
and faster./

Also (wrt 1.5), is it recommended to dump and load them when possible
between such upgrades? Based on the 1.5 release notes I'll get the new
features of 1.5 by just preforming the upgrade operation, but the
svnadmin upgrade subcommand says two things that lead me to believe a
dump and load would be better when possible:
    -/the upgrade performs only the minimum amount of work needed to
accomplish this/
    -/It does not guarantee the most optimized repository state as a
dump and load would./

Thanks much,
    -Steve
Received on 2008-09-10 16:04:36 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.