Péter wrote on Thu, 15 Feb 2018 19:47 +0100:
> [I am not a list member]
>
> In the proposed FSX backend,
> [ https://subversion.apache.org/docs/release-notes/1.9.html#fsx ]
> what type of deltas is planned? Deltas against an older - or newer revision?
> [ http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas ]
> FSFS-like way, or BDB-like way?
>
> Please explain it, why was that chosen. Why is optimal. Or, if not quite
> decided/fixed, please consider carefully.
>
FSFS and FSX are designed around the assumption that the storage backing
older revisions is immutable. The design relies on that immutability
via the way newer revisions refer data in older revisions. Consequently,
both of these backends store new revisions as deltas against older
revisions.
In principle, it is possible to write a compiler that takes as input a
FSFS repository with forward-walking deltas and generates another FSFS
with equivalent contents stored as backwards-walking deltas. It is
possible that with format 7's logical addressing this surgery could even
be performed on a repository in situ, although I haven't worked out
whether it would require taking the repository offline for the duration
(the transformation might break reader invariants).
> I know almost nothing (nor want to) about the internals ("fulltext and
> txdelta caching" etc.), but:
> I would (as everybody :) prefer the variant which uses less space (less
> cache, maybe only one - the last revision), and
> at the same time less time for extracting revision, with strong weight
> to the last (just added) revision, and the last
> few revisions.
>
The way to think about it is through the lens of trade-offs. FSFS's
design choices result in "checkout HEAD" being an expensive operation,
but in exchange for that, FSFS has a form of 'forward security' --- old
revisions would never get corrupted after they were committed --- which
BDB lacks.
> With say, 100000 revisions, when someone checks out the last revision:
> svn starts (would start, with the FSX backend)
> with the 30 years old, "fossile" ancient revision? (It would be case
> with the "FSFS-like way".) Which has nothing common
> with the recent revisions? And applies (at least) 17 deltas (patches)?
> Of which many deltas are very "heavy" (huge
> changings, complete rewritings)?.. I would marvel at that and do not
> understand the reasons..
Note that when the delta is larger than the file it results in,
Subversion stores a compressed fulltext rather than a delta. Your
example of a file that has undergone multiple complete rewrites might
exercise that logic, which will shorten the walk.
I'm not sure why you say "at least" 17 deltas. The default value of
max-linear-deltification (see fsfs.conf) is 16, meaning that no fulltext
will require 17 delta applications to produce.
Cheers,
Daniel
Received on 2018-02-15 22:11:07 CET