Repository migrated via SVNSYNC is much smaller than one migrated using SVNADMIN DUMP/LOAD
From: Christopher Lamb <christopher.lamb_at_ch.ibm.com>
Date: Thu, 28 Aug 2014 18:12:21 +0200
we are in the process of migrating a SVN repository from Windows to Linux.
While experimenting how best to do this I have tried using both SVNADMIN
Original repo size 5.51 GB
Almost 19,000 revisions
SVN version 1.5.1
Windows Server 2003
SVN version 1.7.14 (r1542130)
Oracle Enterprise Linux 7.0
In both cases SVN was installed as an executable (i.e. not compiled or
modified by us).
I first attempted a migration using SVNADMIN DUMP / LOAD. This gave me a
dump file of 10.8 GB. However, as we encountered the" E125005: Cannot
accept non-LF line endings in 'svn:log' property" error (more of which at
the bottom of this mail), I also tried migrations using SVNSYNC and
SVNRDUMP, as these tools should auto-correct the non LF line-endings.
Migrating using SVNADMIN DUMP / LOAD, I get a target repo of 4.5 GB
Migrating using SVNSYNC, I get a target repo of 149 MB! I have tried
running SVNSYNC from the target machine (OEL 7.0), and from the source
machine (Win 2003), and get the same result. SVNRDUMP also gives a repo of
To eliminate OEL 7.0 / SVN 1.7.14 as factors, I also did a test migration
via SVNSYNC to SVN on an OEL 6.5 running SVN 1.6.11 (r934486). This gave a
repo of 148 MB.
So SVNADMIN gives me a 4.5 GB repo, which is close in size to the original
repo size (5.51 GB), but SVNSYNC & SVNRDUMP give me 149 MB repos!
Drilling down into the file system of the repos, I can see that:
a) the revprops directories of SVNADMIN and SVNSYNC loaded repos are both
b) the revs directories contain a similar number of files, but have
significant size differences:
SVN LIST gives results for the repo loaded by SVNADMIN, but nothing for
those loaded via SVNSYNC.
Any ideas what is going wrong with SVNSYNC? Have I missed anything? I have
googled myself to near death, but cannot find any similar reports.
Thanks in advance for your help
p.s, on the topic of E125005:
The various sed based solutions suggested on
I did not want to use -bypass-prop-validation, as this just delays the
problem until a later date.
I ended up using the SVN 1.5.1 SVNSYNC (which also throws this error) to
identify the affected properties, then corrected them via svn propedit,
editing one property higher than the last revision reported.
svn propedit svn:log svn://otms/repo_source --username XXXX --password
In most cases, just saving the property "unchanged" in vi was enough to
This is an archived mail posted to the Subversion Users mailing list.