<div dir="ltr">Hi Shimi and Erez,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 23, 2016 at 12:53 PM, shimi <span dir="ltr"><<a href="mailto:linux-il@shimi.net" target="_blank">linux-il@shimi.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Mar 23, 2016 at 9:22 AM, Erez D <span dir="ltr"><<a href="mailto:erez0001@gmail.com" target="_blank">erez0001@gmail.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>hi<br><br></div>i have a running mysql server, and want to be able to restore it to any day, with as little backup space as needed<br><br></div>i do mysqldump to the same file every day then commit the file with "svn ci"<br></div>the idea is that if there are no changes, it takes no space<br><br></div>it works well if i just append entries to a database, as svn will just save the changes<br></div><br>however, if i insert a record, and for instance the dump file has 5 record at every line<br></div>then the change is big and actually svn will save most of the file though there is a very small change actually.<br></div><div><br><div><div><div><div>another issue - if the records hold changing info like timestamps etc.<br><br></div><div>any idea ?<br></div><br></div></div></div></div></div></blockquote><div><br></div></div></div><div>What about xdelta[1] and saving the .xdelta files ? (from last copy or original copy - your choice, but the cost of choosing the former to save space would be that you'll have to roll the opposite operation in sequence for any recovery)<br><br></div></div></div></div></blockquote><div><br></div><div>Subversion already uses xdelta (or its alternative vdelta) internally for keeping track of binary diffs, so this will likely not buy you much (and add a lot of complexity to the process). I believe git and mercurial/hg can handle binary diffs well in a similar manner. As a result, one cannot rely on the textual "diff -u" output to accurately indicate the change size (e.g: changing one byte in a line of thousands of bytes will yield a thousands-bytes diff -u , but be a very small binary change).<br><br></div><div>Regards,<br><br></div><div>— Shlomi Fish <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>-- Shimi<br><br>[1] <a href="http://xdelta.org/" target="_blank">http://xdelta.org/</a> <br></div></div></div></div>
<br>_______________________________________________<br>
Linux-il mailing list<br>
<a href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a><br>
<a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" rel="noreferrer" target="_blank">http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">------------------------------------------<br>Shlomi Fish <a href="http://www.shlomifish.org/" target="_blank">http://www.shlomifish.org/</a><br><br>Chuck Norris helps the gods that help themselves.<br><br>Please reply to list if it's a mailing list post - <a href="http://shlom.in/reply" target="_blank">http://shlom.in/reply</a> .<br></div></div>
</div></div>