Patch in progress (v1) at: https://paste.apache.org/yx7k
The point of this exercise is not to provide user-level commands but to
abstract the relevant APIs so they will be ready for use in implementing new
features, of which shelving is the current target.
There are 5 parts:
* svn_client__wc_editor()
- a delta editor that applies changes as local modifications to a WC
* svn_client__wc_replay()
- a delta editor driver that pushes the WC's local mods out to an editor
(like in a commit)
* get_dumpstream_loader()
- a dump stream loader that drives a delta editor
* svn_repos__get_dump_editor()
- a delta editor that writes changes (for one revision) to a dump stream
* user-level commands and glue logic to drive those, for testing
- 'x-wc-dump' connects wc_replay to the dump stream writer (dump_editor)
- 'x-wc-load' connects dumpstream_loader to the wc_editor
(WC-local-mods)
^ v
^ v
(delta-editor-API)
^ v
^ v
(dump-stream)
== svn_client__wc_editor() ==
No such editor existed. The largest subset I found was in copy_foreign.c, where
an implementation exists specifically to add a copied directory tree. I have
begun extending it to support all editor operations.
This part is half completed.
== svn_client__wc_replay() ==
This is exposed by a wrapper around some of the existing commit code.
This part is complete except for ancillary considerations (such as externals).
== get_dumpstream_loader() ==
The closest existing implementation is in 'svnrdump load', where indeed such an
editor exists, however it is both coupled to the RA layer and coupled to
svnrdump's particular needs (which include remapping revision numbers and
mergeinfo, checking and canonicalizing properties).
I copied the essential parts from there to create a new implementation. This is
functionally complete.
This implementation is not far off being a generic core of a dump-stream loader
(for one revision record). The rest of svnrdump's functionality -- and quite
likely svnadmin load as well -- should be rewritten around it, with wrappers
and/or through callbacks added to the core.
== svn_repos__get_dump_editor() ==
This exists -- I recently extracted it from svnrdump -- and is working and
tested by the svnrdump tests.
(I am still working to adapt 'svnadmin dump' to use this instead of its own
tightly coupled implementation.)
== Library organization ==
Dump stream loader and writer implementations are currently in libsvn_repos.
Libsvn_repos is not directly linked from libsvn_client. It is linked
indirectly, via libsvn_ra. When I try to call libsvn_repos functions directly
from libsvn_client on Linux, without modifying the build configuration, it
fails to link, but if libsvn_client calls an intermediate pass-through function
in libsvn_ra which calls into libsvn_repos, then the link succeeds.
The dump stream loader and writer could belong in libsvn_delta, as
serializations of the delta editor. Libsvn_delta is linked directly both from
libsvn_client and from libsvn_repos.
It seems more right to me to put the dumpfile serialization functions into
libsvn_delta than either to use an RA layer passthough (as this has nothing to
do with client-server communications) or to declare that libsvn_client now
depends directly on libsvn_repos, but I welcome other thoughts on any and all
of this.
--
- Julian
