Nico Kadel-Garcia wrote on Sat, Aug 07, 2010 at 07:49:34 -0400:
> 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.
This is flatly wrong. 'hotcopy' is *not* a wrapper around 'dump|load'.
> 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.
OK.
> * A working copy, generated by a simple filesystem copy or svnadmin
For obvious reasons, I wouldn't call it a "working copy" :-)
> 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.
'svnadmin hotcopy' doesn't do 'svnadmin verify' or any other sort of
verification. It does check the format numbers, but not much more.
> * Run the 'svnadmin upgrade' on that copy to upgrade in place, with
> the absolutely minimal changes.
Yes.
> * Run 'svnadmin hotcopy' to get the new optimized version.
>
Again, wrong: for example, 'hotcopy' doesn't populate rep-cache.db.
> 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.
Log *messages*, not log files.
Received on 2010-08-07 14:09:12 CEST