A summary of some plumbing work needed to make shelving complete and robust.
Shelving fundamentally moves potentially committable changes out of and into the main WC storage. That would be easy if the WC had clean APIs for getting changes out of and into it. The present implementation of shelving is severely restricted because no such APIs are currently accessible. The delta-editor API (svn_delta_editor_t) is the correct API for that -- it supports all committable changes in the WC including copy operations. Other APIs such as those used for 'diff' are not suitable. (Initially I assumed they would be, but the "copy-from" history pointers that create layered copies in a pending commit do not make sense in a general difference between an arbitrary pair of content snapshots.) Getting changes out of a WC through a delta-editor API is currently implemented only by the 'commit' code path, and is hard-wired to that usage. => We need to decouple the 'commit' code path so we can feed changes out of a WC to any delta-editor (and then feed it to a shelf). Getting changes into a WC through a delta-editor API is currently implemented only within the 'merge' code. => We need to decouple 'merge changes' from 'apply changes to the WC' so we can feed changes into the WC from any edit-driver (and then drive it from a shelf). To develop and test these decouplings, it is useful to connect these new WC APIs to another already existing source or destination. When both "out of WC" and "into WC" APIs are developed, then we should be able to connect "out of WC-1" to "into WC-2" and so clone a WC, and test that the resulting WC-2 is indeed equivalent to WC-1. Before both "out of WC" and "into WC" APIs are developed, we could potentially connect to the one other pair of existing delta-editor APIs that fully support "copy": the repository dump/load APIs. 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. => We need to unify these two implementations, to have a clean re-usable dump editor. 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. -- - Julian
