This is an archive of the discontinued Mercurial Phabricator instance.

repository: establish API for emitting revision deltas
ClosedPublic

Authored by indygreg on Aug 9 2018, 7:12 PM.

Details

Summary

With our revision delta and revision delta request interfaces
defined, it is now time to define a method on storage interfaces
for using them.

So far, the only storage interface that is well-defined and used
is file storage. So that is the only interface we need to add a
method on.

We define an `emitrevisiondeltas()` method that takes an
iterable of `irevisiondeltarequest`s and turns them into
`irevisiondelta` instances.

changegroup._handlerevisiondeltarequest() and the looping logic
from changegroup.deltagroup() has effectively been moved to
revlog.emitrevisiondeltas().

Our filelog wrapper class proxies its emitrevisiondeltas() to
the internal revlog instance.

The simple store test extension used to verify sanity of storage
abstractions has also implemented emitrevisiondeltas() for
file storage and the test harness when run with this extension doesn't
seem to exhibit any regressions.

Rather than create a shared type to represent revision deltas,
each storage backend has its own type and the class name identifies
where the revision delta was derived from.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

indygreg created this revision.Aug 9 2018, 7:12 PM

There might be room to structure this as a pair of APIs: build delta requests and generate them. But I'm having a difficult time reconciling how ellipsis mode would fit in and how callbacks would work

A benefit of having a pair of functions is that the storage implementation can emit any object it wants to describe the revision deltas that should be generated. Of course, at the point where the storage implementation can figure out the delta request logic, you might as well have a single function in the storage layer that replaces changegroup.deltagroup()!

One of the reasons I would like to have an abstraction for delta requests and a single function to process them is it can lead to easy-to-drop-in caching. For example, it should be possible to write an extension that uses redis or some other in-memory store to service the revisiondeltarequest -> revisiondelta handling.

indygreg updated this revision to Diff 10321.Aug 10 2018, 1:36 PM

Nice work, this layering feels saner to me.

Regarding the request/result split for caching, while I agree that caching deltas is something worth pursuing (it was an enormous win on code.google.com!) it's also not something anyone has cared a ton about, and I could also see it living in the store layer directly.

This revision was automatically updated to reflect the committed changes.