[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn 1.8 migration - directory deltification and revprop packing

From: Thomas Harold <thomas-lists_at_nybeta.com>
Date: Mon, 05 Aug 2013 14:28:52 -0400

On 8/2/2013 3:21 PM, Thomas Harold wrote:
> Our migration process:
>
> 0. svnadmin verify oldreponame
>
> 1. svnadmin dump oldreponame
>
> 2. svnadmin create newreponame
>
> 3. Modify db/fsfs.conf
>
> [rep-sharing]
> enable-rep-sharing = true # defaults to true in 1.8
>
> [deltification]
> enable-dir-deltification = true
> enable-props-deltification = true
>
> This can be done in automated fashion with sed (or awk).
>
> sed 's/^[#[:space:]]*enable-rep-sharing =
> false[#[:space:]]*$/enable-rep-sharing =
> true/g;s/^[#[:space:]]*enable-dir-deltification =
> false[#[:space:]]*$/enable-dir-deltification =
> true/g;s/^[#[:space:]]*enable-props-deltification =
> false[#[:space:]]*$/enable-props-deltification = true/g' --in-place=bkp
> newreponame/db/fsfs.conf
>
> Naturally, you should have a backup of your db/fsfs.conf file. While
> sed creates one with --in-place=bkp, you should not rely solely on that
> method.
>
> 4. svnadmin load newreponame
>
> 5. svnadmin pack newreponame
> - Not all of our repos were packed
>

Sample repository size changes for us:

OLD: Size: 52MB Files: 1310
NEW: Size: 52MB Files: 1313
- This one is a lot of "add file, then remove it a few days later
without modifications".

OLD: Size: 151MB Files: 18574
NEW: Size: 60MB Files: 633
- Apache HTTP log files stored with FSVS, 40% of original size

OLD: Size: 151MB Files: 2540
NEW: Size: 126MB Files: 551
- Linux server configuration, stored using FSVS, 83% of original

OLD: Size: 473MB Files: 600
NEW: Size: 424MB Files: 603
- Another FSVS repository, 90% of original

OLD: Size: 1080MB Files: 2582
NEW: Size: 964MB Files: 1785
- FSVS repository, 69% of original

I haven't seen any repositories bloat up to larger then the original
size, but I'm still working through converting our old v1.6 repositories
to the v1.8 format.

The bottlenecks for us in the dump/load cycle are:
- CPU for "svnadmin verify" step
- GZIP (using -5 option) during dump step
- Disk contention during the "svnadmin load" step
Received on 2013-08-05 20:29:34 CEST

This is an archived mail posted to the Subversion Users mailing list.