Jim Blandy <jimb@savonarola.red-bean.com> writes:
> The delayed text deltas are Karl and Ben's thing, but if they don't
> provide a way to delay file property deltas, that sounds like an
> oversight. It seems to me that the delta producer should be able to
> send property changes and text changes at any time.
Well, here's the situation:
The current interface handles text deltas in a windowy way, so a big
txdelta doesn't have to all be in memory at once. But it does not
handle property deltas this way, because they're likely to be small
and handling them simply makes some things easier right now. That's
why the change_foo_prop() functions take the entire key and entire
value as arguments, instead of doing things in the more careful (but
more complex) way that the txdelta functions do.
A similar concern motivated postfix txdeltas: because txdeltas are
relatively bulky, we don't want to wait until they've gone over the
network before we can discover a conflict. So we transmit a summary
of the changes first (the tree delta, with references in place of the
actual txdeltas), and then if there is still no conflict, we transmit
the txdeltas that match those dangling references.
Someday, we may want to make the sacrifice in complexity to handle
large properties more efficiently. If and when we do that, that's the
time to a) have real prop deltas, and b) allow postfix prop deltas.
But it wouldn't make sense to do one and not the other. So they're
both implemented in the simple, no-fuss way right now.
Received on Sat Oct 21 14:36:09 2006