One thing to remember: if revision properties are being changed (i.e. the
pre-revprop-change hook allows them) then those changes will need to be
captured and replayed into the loaded repository "somehow" or changes to
revisions prior to -rNEXTREV will be lost.
On Thu, Jun 16, 2016 at 6:49 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> >> 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
>
--
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
*T *925-396-1125
*E* doug.robinson_at_wandisco.com
*www.wandisco.com <http://www.wandisco.com/>*
--
Learn how WANdisco Fusion solves Hadoop data protection and scalability
challenges <http://www.wandisco.com/hadoop/wd-fusion>
Listed on the London Stock Exchange: WAND
<http://www.bloomberg.com/quote/WAND:LN>
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone. Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized. The views and
opinions expressed in this e-mail message are the author's own and may not
reflect the views and opinions of WANdisco, unless the author is authorized
by WANdisco to express such views or opinions on its behalf. All email
sent to or from this address is subject to electronic storage and review by
WANdisco. Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.
Received on 2016-06-16 19:43:06 CEST