1

I currently maintain a server that host multiple Subversion repositories. On an other server I mirror the production repositories using svnsync. There are over 100 repositories to be synched on the mirror server, for most of them they have the same size (not size on disk) on both server.

My concern is that for a few of them the size on the production server and the mirror server is not the same (a difference of 100mb+ for some of them).

My question to you guys is: is it normal and why does it happen?

Some additional information to better understand my situation:

  • Both server are Windows Server 2003,
  • Production server uses Subversion 1.6.6,
  • Mirror server uses Subversion 1.6.13,

I have also run the following tests:

  1. Checked out a broken repository from production and from mirror (at latest revision) and compared their log and size and they are both the same. At this point this is not really conclusive but at least they both seem to be working.

  2. used the svnsync command from the server using Subversion 1.6.6 to check out the size of the synched repository and I get the same results as if I had synched from the mirror server using Subversion 1.6.13.

  3. Compared both format from repositories (the one created on production server using Subversion 1.6.6 and the one created for the svnsync command) and they are both the same, using fsfs 4 layout sharded 1000 with format 5.

Thank you for your help.

EDIT: format for clarity.

unwind
  • 391,730
  • 64
  • 469
  • 606
gturc
  • 63
  • 1
  • 8

1 Answers1

1

There are several ways for svnsync'd repositories to be different sizes. These include:

One of the repositories could have been packed using svnadmin pack, that can change the size quite dramatically.

The unversioned revision properties for each revision get copied when the revision is sync'd, but it's possible for the properties of a revision on one repository to be modified/added/deleted, after the sync. (100MB sounds unlikely but is possible.)

Rep-sharing (see fsfs.conf) can be enabled on one FSFS repository and not the other. Rep-sharing may increase or decrease the size of a repository, it depends on whether the index takes up more space than sharing saves.

If Subversion exclusive file locks are used these take space in the master repository. They are not copied by svnsync. There was a long standing bug that caused locks to take up space after being released, see issue 3667.

On disk a repository is just a directory tree of files. It's possible to put arbitrary, non-repository, files inside a repository directory tree. Any such files never get copied by svnsync.

vinnyjames
  • 2,040
  • 18
  • 26
  • Users do not have access to the server, thus svnadmin. I am the only one who could have used svnadmin pack or put "extra" files inside the tree of files. File locks however might be the reason why. Thank you very much, I will investigate this possibility. – gturc Apr 20 '11 at 18:37
  • I think I have found the awnser to my question but I am not 100% of it's meaning. I drilled down the directories for both repositories and found that the extra 200mb for one of them was located in the **/db/txn-protorevs** directory, which, from what I can understand from [this link](http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_fs_fs/structure), is a folder to put transactions in progress which obviously do not get copied over by svnsync. – gturc Apr 20 '11 at 18:53
  • that sounds like the culprit. you may want to look at `svnadmin lstxns /path/to/repo` as well. under certain circumstances these can be left behind after failed commits and may be fairly old. next time you have a maintenance window and you know they're not in-flight transactions you can also `svnadmin rmtxn xyz` – vinnyjames Apr 20 '11 at 22:21