svn x-wc-dump wc1 | svn x-wc-load wc2

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