On Wed, Feb 01, 2012 at 09:49:58AM -0800, David Chapman wrote:
> On 2/1/2012 9:26 AM, James Boden wrote:
> >Earlier it was stated by Andy
> >>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. :-(
I would recommend 'svnadmin upgrade' instead of dump/load, unless you
are already having specific problems addressed by new features which
require a dump/load to be effective for existing revision data.
So if, for example, the size or the number of files in your existing
repositories does not bother you, there is no point in wasting time
for a dump/load cycle. 'svnadmin upgrade' takes virtually no time at all.
You may even choose not to upgrade your repositories at all.
They will continue operating like they did with a 1.4 server.
But you will again be running a supported server version which receives
bug fixes in point releases, and newly created repositories will use
the new features automatically.
If users of existing repositories do not need the new features
offered by an upgrade then this is probably your best option.
Received on 2012-02-01 19:03:01 CET