Hello, On 28/08/14 17:12, Christopher Lamb wrote: > While experimenting how best to do this I have tried using both SVNADMIN > DUMP / LOAD, SVNSYNC, and even SVNRDUMP. The resulting target repos have > dramatically different sizes, hence this mail. > > > Original repo size 5.51 GB > Almost 19,000 revisions > SVN version 1.5.1 > FSFS > > Target repo(s) > SVN version 1.7.14 (r1542130) > FSFS > [10.8GiB with dump load, 149 MiB with svnsync]
1. Representation sharing in 1.6: https://subversion.apache.org/docs/release-notes/1.6.html#filesystem-improvements 2. When using svnsync, make sure the reading user has fully recursive read access, and no subtree has restrictive controls. From http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication.svnsync-partial > svnsync isn't limited to full copies of everything which lives in a > repository. It can handle various shades of partial replication, too. For > example, while it isn't very commonplace to do so, svnsync does gracefully > mirror repositories in which the user as whom it authenticates has only > partial read access. It simply copies only the bits of the repository that it > is permitted to see. Obviously, such a mirror is not useful as a backup > solution. Obviously in your case it may sync partially (without message) and thus result in a smaller repository. You will get an initial hint by printing the full HEAD tree of the root of each repository. Any differences there would point to a problem. As you get two different size, both are likely to occur, while you only want #1 for a migration. Regards, Andreas
