As of commit #240, we're punting on deltifying files
larger than the svn_txdelta_window_size. This isn't as
extreme as it sounds -- for example, only 5 files in the
Subversion repository are larger than that, and they're
fairly static -- but obviously won't scale very well
when people want to version large collections of large
objects that get frequently revised.
(If you ever want to see why we punt on them, disable
the check in reps-strings.c:svn_fs__rep_deltify() and
add some printf's to rep_read_range() and its callers.
You'll see re-undeltification increase fibonaccically
as the second window in each delta makes src_data
references into one or more previous windows of a
deltified base_rep; this is unavoidable without either
a sophisticated caching scheme to keep it from redoing
work it did once and then tossed, or a delta combiner.
And if the caching scheme happens in memory, then it is
very easy to end up with the equivalent of having no
upper limit on delta window size, which would defeat
the whole purpose of having the windows in the first
place. Grin. Sigh.)
A true delta combiner is probably two weeks of work; it
would compose a series of successively applicable deltas
into one, adjust ops as it goes and preserving only the
new data needed by the final composition. See the file
notes/fs-improvements.txt and comments in reps-strings.c
for more.
Critical 