subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject Shelve & checkpoint - next steps
Date Mon, 16 Apr 2018 16:53:55 GMT
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

View raw message