Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 284C89E48 for ; Wed, 1 Feb 2012 18:02:58 +0000 (UTC) Received: (qmail 14050 invoked by uid 500); 1 Feb 2012 18:02:57 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 14002 invoked by uid 500); 1 Feb 2012 18:02:56 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 13995 invoked by uid 99); 1 Feb 2012 18:02:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 18:02:56 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.109.42.8] (HELO einhorn.in-berlin.de) (192.109.42.8) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Feb 2012 18:02:47 +0000 X-Envelope-From: stsp@stsp.name Received: from ted.stsp.name (ted.stsp.name [217.197.84.34]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id q11I2GY6030833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Feb 2012 19:02:16 +0100 Received: from ted.stsp.name (stsp@localhost [127.0.0.1]) by ted.stsp.name (8.14.5/8.14.3) with ESMTP id q11I2GRJ009886; Wed, 1 Feb 2012 19:02:16 +0100 (CET) Received: (from stsp@localhost) by ted.stsp.name (8.14.5/8.14.3/Submit) id q11I2FXx019335; Wed, 1 Feb 2012 19:02:15 +0100 (CET) Date: Wed, 1 Feb 2012 19:02:15 +0100 From: Stefan Sperling To: David Chapman Cc: James Boden , Andy Levy , Giulio Troccoli , "users@subversion.apache.org" Subject: Re: Upgrade Subversion 1.4.3 Message-ID: <20120201180215.GM16977@ted.stsp.name> Mail-Followup-To: David Chapman , James Boden , Andy Levy , Giulio Troccoli , "users@subversion.apache.org" References: <5DCC05F8EEFBC740BBD7D5B2C58C1EA10173AF@DLLRMAILSTORE.dllr.state.md.us> <20120201151803.GF16977@ted.stsp.name> <5DCC05F8EEFBC740BBD7D5B2C58C1EA10173DF@DLLRMAILSTORE.dllr.state.md.us> <4F296801.4030807@mediatelgroup.co.uk> <5DCC05F8EEFBC740BBD7D5B2C58C1EA10173ED@DLLRMAILSTORE.dllr.state.md.us> <5DCC05F8EEFBC740BBD7D5B2C58C1EA101740B@DLLRMAILSTORE.dllr.state.md.us> <20120201171620.GJ16977@ted.stsp.name> <5DCC05F8EEFBC740BBD7D5B2C58C1EA1017427@DLLRMAILSTORE.dllr.state.md.us> <4F297B46.5010600@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F297B46.5010600@acm.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 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.