RFC: idioms/names for delta vs changes

[Martin Pool]

On Thu, Nov 13, 2008 at 8:01 AM, Robert Collins
<robertc at robertcollins.net> wrote:
> So we have throughout the bzrlib code base two similar concepts (and
> many variations of each for different objects and so on).
>
> One that is a recipe for regenerating an instance B from some inputs. We
> usually call this a delta. Its not reversible (you can't get to the
> inputs given B and the recipe).
>
> One that is a symmetric description of changes between instance A and
> instance B. We don't seem to have a consistent name for this, but we do
> have 'iter_changes' on trees. Unidiff patches are symmetric in this
> fashion.
>
> Why two things? For serialisation at least, a delta is often much more
> efficient than a 'changes'. knits are slightly more efficient than
> unidiff style patches, but groupcompress is much more efficient than
> knits. Neither are reversible. The reversible aspect only matters if we
> want to be able to traverse in a bidirectional fashion (but this can be
> surprisingly useful; symmetric deltas inside knits would have let us
> handle deletes without full deserialisation years ago).
>
> I think the situation is less clear than it could be. It might be a good
> idea to set some nomenclature so that its clear when code is offering a
> reversible interface (e.g. changes) or when its offering a 'permit later
> regeneration' interface.

I agree that clearing this up would be good.  There's another
dimension too, which is whether it provides a 'luxurious' python
object interface (eg TreeDelta) or a (much cheaper) iterator of tuples
(eg iter_changes).  I don't know if we really want to continue
providing the first as a general interface, because of the cost,
though maybe we can provide functions that collate the lower level
deltas for easier use by less performance sensitive code.

As you say many times the difference is just whether deletions are
fully described or not, and it's worth considering whether an
interface that omits them will cause bugs relating to deletion.

-- 
Martin <http://launchpad.net/~mbp/>