I'm trying to use svn to backup SQL files because I'd like to have the
whole versioned history of the database at my fingertips instead of
having to keep around a big pile of DVDs. Since each successive SQL dump
has relatively few changes I thought this would be perfect for svn. To
make it easier on svn I dumped each table into its own SQL file, ordered
by primary key. Most files are small but the biggest is 63 MB. I
expected the first commit to take a lot of space and subsequent commits
to use only a little space each, but instead I got the opposite!
rev1: initial commit ~2M lines
2,059,337 lines 257,095,356 bytes
-> repo/db/revs/1 is 85,119,507 bytes
rev2: -74,399 +345,127 lines
2,330,075 lines 290,885,872 bytes
-> repo/db/revs/2 is 100,085,702 bytes!
rev3: -27,881 +38,092 lines
2,340,286 lines 292,217,590 bytes
-> repo/db/revs/3 is 154,831,162 bytes!
Can anyone explain to me what is going on? I expected revision 3, with
the smallest changeset, to have the smallest file size in the repository
but instead it's the biggest. Even if I take into account the
skip-deltas[1] algorithm, rev3 should use rev2 as the base delta,
resulting in a small revision file size. I'm very confused.
[1] http://svn.collab.net/repos/svn/trunk/notes/skip-deltas
PS: is there any way to disable the skip-deltas algo? If possible I'd
like to always use N-1 as the base delta because I care more about space
savings for this particular case.
PPS: In an older thread[2] it was suggested to use rdiff-backup for
this, but I'd like to have some of the svn niceties like versioned file
renaming.
[2] http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=48408
Thanks in advance for any information on this behavior,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 5 11:24:29 2007