Question on work-flow for big binary files

[Marcus Lindblom]

Paul R wrote:
> Hi marcus,
> 
> On Thu, 18 Dec 2008 17:46:13 +0100, Marcus Lindblom <macke at yar.nu> said:
> 
> Marcus> SVN claims to have an efficient server-side diff algorirthm that
> Marcus> also works on binary files. I think it's rather recent.
> 
> Yes but still, some binary data file will just not be diff-able that
> way. Imagine a bitmap file at version 1. You insert a row of pixel at
> top and commit version 2. The diff might be much biger than the new file
> itself (I have not carried the experimentation in this particular case,
> this is just to give a simple example).

I agree. Especially with compressed formats, things can change a lot if 
you edit something in the first part.

> To me, binary revisions are not cheap at all. So the workflow is not
> quiet the same as for code, because with text files it will take about
> just the same space wether you commit a patch in 1 or in 10 revisions.
> With binary, each revision will have either a big or a huge cost in
> terms of space. To my knowledge, svn tries hard to keep it only big.

Sounds reasonable. It would still be interesting to see just how this 
hit is, and what compression gives you. OTOH, retaining the actual files 
for some time (with rsnapshot) is probably good enough, and makes the 
efficient-binary-diff issue a bit less pressing.

OTOH, I think svn still keeps an extra copy on disc for diffs & reverts, 
even for large binaries,, so it's not very space-efficient on the 
client. But there's always a tradeoff there.

Cheers,
/Marcus