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

Re: Upgrade Subversion 1.4.3

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Wed, 1 Feb 2012 14:45:17 -0600

On Wed, Feb 1, 2012 at 11:49 AM, David Chapman <dcchapman_at_acm.org> wrote:
>
>>
>>> Actually the Working Copies are automatically upgraded when "touched" for
>>> the first time by the new version. The Repositories are NOT automatically
>>> upgraded, but it's a manual step through svnadmin upgrade (which mean
>>> *you*
>>> decide if and when to upgrade the repository).
>>
>> that the repositories could use the svnadmin upgrade.  Would I still have
>> to do a dump/reload if I did the upgrade?
>>
>
> Not required, but strongly encouraged.  If your repository is large (many
> gigabytes) and you have many users, the downtime for a dump/load cycle can
> be problematic.  But if you can afford to have the repository down for a
> little longer than the time required to switch the server from the old
> Subversion release to the new Subversion release, a dump/load can give you
> many benefits - not the least of which is repository sharding, to avoid
> having tens of thousands of revision files in a single directory.
>
> Now you know why many admins work late nights or weekends.  :-(

Alternatively you can make a new repository and use svnsync to copy
the old content over, then substitute the new for the old at a point
when it is caught up. I'm not sure the exact steps are well
documented, but it has the advantage of working incrementally so you
can start well ahead of cutover and the final sync happens quickly and
without needing intermediate storage space for the dump copy.

-- 
   Les Mikesell
     lesmikesell_at_gmail.com
Received on 2012-02-01 21:45:50 CET

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.