On Fri, Aug 6, 2010 at 10:20 AM, Bob Archer <bob.arc...@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.
