Re: Plumbing work to make shelving complete and robust

Julian Foad wrote:
> [...] There are
> currently two implementations of a "dump" editor and neither is
> immediately usable. The one in "svnadmin dump" is not written as a clean
> editor, and instead calls directly into the FS layer to fetch its data.
> The one in "svnrdump" is clean but does not support all the features of
> the other such as non-delta mode and verify mode.

For connecting to the WC and to shelving, it is not a problem that the "svnrdump" dump editor lacks support for those features. It's a problem that the implementation is located in the "svnrdump" executable rather than in a library, but that is easy to overcome.

> => We need to unify these two implementations, to have a clean re-
> usable dump editor.

So moving the "svnrdump" implementation into the library can be the first step (done: r1838835), and unifying can be the second step.

The attached patch 'unifying-dump-editors-1.patch' goes some way towards that.

> The delta edit driver in "svnadmin load" also does not seem to be shared
> with the one in "svnrdump load".
>
> => We need to unify these two implementations, to have a re-usable
> load edit-driver.
>
> To be clear, re-using the dump/load functionality is not a direct
> requirement for shelving; rather, it is an existing functionality that
> supports input and output of shelvable changes. By providing an input
> and output mechanism that can be attached to various APIs (repository,
> WC, and shelves) it is useful for testing that the APIs all work
> consistently.

Only by implementing more than one edit driver for each editor (and vice versa) can we prove that the components are cleanly separated by an API and thus re-usable.

Then there is the need for a test framework that can generate all different combinations of changes and test each of the subsystems with all of those changes.

These improvements are not just to benefit shelving. In the longer term, if we are to make a major improvement like supporting moves/renames properly, in my opinion we need to do it starting from a baseline where we consistently and cleanly use APIs that encode the current semantics of versioned changes, and then migrate those.

-- 
- Julian