Next steps for shelve & checkpoint.

* change the storage so we can shelve (large) binary files

* API abstraction to access shelf data

* store and retrieve base revisions

* more complete testing -- we should have a way of testing all possible kinds of change

=== Storage for binary files ===

I made the shelve function walk the WC itself (r1829291), so we can intercept binary files at that point and do something other than diff with them.

From r1829295, for binary files it uses git diff binary literal format. This works for a stop-gap, but is inefficient for large files.

Ideally shelves will be able to share the WC pristine store for storing whole file contents. Storing full texts rather than a delta might provide a satisfactory balance of speed and size in practice.

=== API abstraction ===

We need libsvn_client APIs to be able to access shelves in the same way as "regular" WC data: export|diff|cat|propget|... for data stored in any shelf. The result of any such API operating on a shelf should be analogous to how the same function would operate on the WC if we first unshelved the change.

A possible starting point, currently implemented on the 'shelve-checkpoint' branch, is to modify svn_opt_revision_t and the revision-number parsing to accept a shelf name as another kind of revision specifier. This (and the other revprop functions) works so far:

  $ svn propget -r foo --revprop svn:log
  This is the log message of shelf 'foo'.

=== Store and retrieve base revisions ===

Storing the revision number metadata is easy. Svn diff format has always written the base revision of each file in the diff header. The recent 'svn info --viewspec' prototype now provides a way to write a complete description of the revisions and 'shape' (depth and switch settings) of a WC.

Reading it out is a SMOP. Doing something with it -- that is, doing a 3-way-merge instead of a 'patch' operation -- is conceptually a SMOP but probably more involved.

Snapshotting the actual content of the base is much more involved if we intend to keep this snapshot attached to each the shelf even though the user runs 'update'. In order to decide whether it is important to do so, I suggest we implement making use of just the revision number metadata and test its performance -- accepting that either repository access or fallback to plain patching would be needed in cases where 'update' has been done.

Glad to hear any thoughts.

- Julian

Reply via email to