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
