Re: thoughts about shelving

Julian Foad wrote:
> Greg Stein wrote:
>> When I envisioned the implementation of shelving, I figured that we would use the sql database to its best effect.

Let me be more concrete.

>> Store new pristines (which is logically just key->fulltext).

Pristine file texts add up to a large fraction of the total disk storage space requirements, so for that reason this would be worth doing, but their management forms only a small subset of the complexity of storing tree changes.

>> Maybe create an artificial wc_id to construct an alternate tree of ACTUAL_NODE entries where you can store node information of the items on the shelf.

What's needed is a consistent API for storing and retrieving tree changes. Such an API is needed for getting changes into and out of a shelf, just the same as for getting changes into and out of the main WC storage. There are 3 parts to such an API relevant to the main WC storage:

1. the base
2. the committable changes
3. uncommittable WC state (conflicts, changelists, etc.)

For (1) the base, the "reporter" is the required API definition, and implementations to both update the base layer and read (report) the base layer through this API exist.

For (2) committable changes, the "delta editor" is the right API, by definition. The client-layer "commit" function of course sends WC changes out through a delta editor API through the RA layer. This implementation is rather tightly coupled to that RA-layer consumer. An implementation of a delta editor API for making changes in the WC doesn't exist at all. And it should.

For (3) uncommittable changes, an interface definition doesn't even exist. My shelving design doesn't attempt to support part 3, largely because I knew the API didn't exist. If it did, it would be relatively easy for shelving to support it.

See my recent comments in https://issues.apache.org/jira/browse/SVN-4745 (Shelving: "shelf-diff").

With these interfaces in place it would be relatively straightforward to implement the logic of shelving. And then making the implementation use the efficient existing DB storage later would become the priority.

But first my task is to put those interfaces in places, uncoupling and extracting the ones that already partly exist and writing the new ones.

- Julian
Received on 2018-09-15 18:41:03 CEST