>> You should rather let the computer spend some time dealing with the dump
>> and load process, instead of spending your own time working around problems
>> and not even knowing if the result of your workarounds will be OK.
>
> Will have to plan a maintenance window then.
> Gah. :)
You can do this with a very small maintenance window. The trick is to
dump+load to a new location, while the old repository is still
accessible (for checkouts and commits). After this is done (can take
hours, or even days, whatever) you note the last revision which was
loaded (or check the revision number with 'svnlook youngest
newrepos'), and start another dump+load where you dump with
'--incremental -rNEXTREV:HEAD' (where NEXTREV is the next revision
that needs to be dumped).
You can iterate over this as long as you keep the old repository open
... At the end you make the original repository inaccessible for a
couple of minutes, while you enable the new one (Caveat: if you move
your new repos in the same disk location as the old one, and you use
Apache httpd to serve it, make sure you restart httpd to reset its
caches).
Hint: for a large repo I strongly suggest building the new repository
(the target of your 'svnadmin load') on very fast storage, even
ramdisk if possible (to copy it over to fixed disk afterwards). It's
the 'svnadmin load' part that is very time-consuming right now (this
will probably be much improved in svn 1.10, with the
--no-flush-to-disk option for 'svnadmin load' [1]).
To be precise, your commands might be:
1) svnadmin create NEWREPOS
(maybe create it on a ramdisk)
2) svnadmin dump -M 1024 OLDREPOS | svnadmin load -M 1024 NEWREPOS
(initial dump+load; you might want to pass -q to dump and/or load
to make it more quiet)
(the -M 1024 gives the process 1024 MB extra ram for caching)
3) svnlook youngest NEWREPOS
(last rev that was loaded -> NEXTREV is this last rev + 1)
4) svnadmin dump --incremental -rNEXTREV:HEAD -M 1024 | svnadmin load
-M 1024 NEWRPOS
5) Make OLDREPOS read-only or completely unavailable
6) Possibly repeat 4) (if new commits happened after 4)
7) Put NEWREPOS online
At my company we recently did a dump+load from a old svn 1.5
repository ("Repository format: 5; Filesystem Type: fsfs; Filesystem
Format: 3; Sharded but unpacked) to the brand new FSFS format 7 (new
in svn 1.9). It went fine with this procedure. Our largest repos was
15 GB with 328000 revisions. We created the new repository on a
ramdisk, the loading was finished in 6 hours. After that we ran
'svnadmin pack' (still on ramdisk), and then copied it to fixed disk.
Some things to watch out for:
- Dump+load does not preserve locks (in REPOS/db/locks), hooks (in
REPOS/hooks) and configuration files (in REPOS/conf). For those, a 'cp
-rp SOURCE TARGET' works well (but this is a good time to review your
hooks and conf files to make sure they are still fine). Make sure the
source repository is offline while you copy the locks, and those might
otherwise be changed in mid-flight.
- You might run into:
> svnadmin: E125005: Invalid property value found in dumpstream; consider
> repairing the
> source or using --bypass-prop-validation while loading.
>
> svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log' property
You can try to repair this in the source repository (with svnadmin
setrevprop) -- I'll post separately about that -- or you might simply
ignore this minor corruption by using --bypass-prop-validation for
'svnadmin load' (you can always repair this later in the new
repository).
- You might run into:
> svnadmin: E125005: Invalid property value found in dumpstream; consider
> repairing the source or using --bypass-prop-validation while loading.
> svnadmin: E125005: Cannot accept non-LF line endings in 'svn:ignore' property
This is more difficult to repair, because 'svn:ignore' is not a
revision property (like svn:log, which can be manipulated with
svnadmin setrevprop), but a *versioned property* (so it's part of
history). Again, you can ignore this with --bypass-prop-validation.
But since this is a corruption "in history", this can only be repaired
with a dump+load, so this might be a good time to try and fix this (or
you'll run into this again in the future). To repair it (which is what
we did), you can use svndumptool [2]. But it only works on dump
*files*, not as part of a pipe. So what we did was: dump that single
(corrupt) revision to a file, repaired it ('svndumptool.py eolfix-prop
svn:ignore svn.dump svn.dump.repaired'), loaded that single dumpfile,
and then continued with a new "piped" command (like step (4) above).
[1] http://svn.apache.org/viewvc?view=revision&revision=1736357
[2] https://github.com/jwiegley/svndumptool
--
Johan
