Problem with large (binary) files

[Simon Butler <si...@icmethods.com>]

"C. Michael Pilato" <cm...@collab.net> wrote on 08/28/2006  
11:35:10 AM:

 > We do client->server deltas using our pristine text-bases for a  
reason
 > -- to reduce the cost of network transfer.  We know that on some
 > networks, this matters (trust me -- many folks I know still use 56k
 > dialup lines), and on some, it really doesn't.  But Subversion  
doesn't
 > know which networks are which.  Only humans do.  And the type of  
network
 > in use isn't a property of the file in question, or even of the  
working
 > copy in question (hello, laptops moving from place to place) --  
it's a
 > condition as ever-changing as the weather in Chicago that has to be
 > evaluated anew each time a commit occurs.

I guess I was thinking that we were only trying to solve the case  
where we
have a largeish binary file and we know, because the user told us, that
the file is not going to deltify well.  This seems to be a very common
problem and the speedup would come from skipping that step and just
sending the entire file.  This problem has nothing to do with network
speed because the real problem is that we are spending a lot of time
trying to deltify the file and the delta being produced is not
significantly smaller than the original.

It sounds like you are trying to solve more problems than just this one,
which is fine.  I just did not realize that people were trying to do  
that.
-------

i would agree with this poster, a mechanism to enable a user to turn off
"deltification" would go a long way to solving this issue.

i know a head of time which of my files are large binary ones that  
don't diff
well, and its no problem at all to add some kind of svn property to  
those.

is this something that the developers on this list think could make  
it into
the 1.5 release?

kind regards.