On Fri, Aug 6, 2010 at 10:20 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> On Thu, Aug 5, 2010 at 9:59 AM, Kriparam Faraday
> Wouldn't he have to run svnadmin upgrade or do a dump/load to get the repository in the newest version format to take advantage of the new storage / merge features?
svnadmin hotcopy works by using dumpload, not filesystem copies.
Whether it preserves the older repoformat is an interesting question.
dump/load certainly wouldn't get his post-commot or svnserve.conf or
other config files, which is part of why hotcopy is so useful.
You're quite right, it does preserve format by default, which is
certainly reasonable default behavior. I suspect that it's still a
good idea to set aside the original filesystem based copy and work
from "hotcopy" generated copies. So, in fact, it takes 3 copies for
full safe upgrade.
* Lock down your repository. Turn off access to it, and move it aside.
* Keep that original copy set aside on tape or locked down in original
format. In theory, you can skip this, but in the paranoid practices of
systems administrators who've had software upgrades break things, this
is a very critical step.
* A working copy, generated by a simple filesystem copy or svnadmin
hotcopy. The advantages of the svnadmin hotcopy are partially that it
confirms if the original data format are, in fact, legible to the new
svnadmin command, but this copy remains in the older format.
* Run the 'svnadmin upgrade' on that copy to upgrade in place, with
the absolutely minimal changes.
* Run 'svnadmin hotcopy' to get the new optimized version.
You could, theoretically, skip that last step and use the very
slightly upgraded version, but you don't get the features such as
re-optimization of databases and I don't believe that you get the
'EOL' repairs to the log files, which are very handy.
Received on 2010-08-07 13:50:14 CEST