> > Being able to supply an "svn:diffasnew" (or a hopefully better one)
> > keyword that instructed the client and the server to treat the file as
> > a complete replacement diff might perhaps be more straightforward.
> > This would not be too severe in terms of effort I expect and wouldn't
> > change anything in the backend storage.
>
> sounds great!
>
> unfortunately my binary files may change only slightly in the
> application that generates them, (eg: i move an inverter on a
> circuit schematic) but the resulting binary is *very* different
> to the previous. there's just no point in diffing these files, the
> delta will be close to just sending the new file over, with no
> processing..
>
> i think this is the case for a lot applications, we can't rely on
> a small change to a user data object showing up as a small
> change to the resulting binary db that stores this change.
I agree that for the vast majority of files diffs may very well not
save much space and are fairly likely to produce very
expensive reconstruct-from-diff operations.
It's likely that, with the relatively low costs of storage that
many people would opt to disable diffing on the binaries (at the
expense of transmission since you're no longer transmitting
only diffs between client and server).
> > ... (someone did mention that another diffing approach
> > was on the cards).
> what are the new diff changes by the way?
That one's beyond my rather recently acquired knowledge of
the Subversion development process (and people involved). It
was mentioned that a cheaper diffing approach existed (called
skip-diffs IIRC). Turn that smile upside-down though - I'm not
even sure that the thought had even begun to speculate about
the merest possibility of this making it's way into a release
any time soon (apologies in advance, for those reading this
backwards, for the blatant borrowing of part of a rather nice
quotation by Douglas Adams).
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 25 04:58:15 2006