Julian Foad wrote on Tue, 09 Jan 2018 13:31 +0000:
Anyway the main point here is: we have in principle a set of tree
snapshots (no matter that each one is stored in the form of a difference
against the base); and we use revision specifiers to refer to the
working and base versions:
Initial implementation: http://svn.apache.org/r1820696 "On the
'shelve-checkpoint' branch: Let revision specifiers access shelves."
I think this proves the principle of using revision specifier syntax to
refer to shelves.
$ svn propset -r foo --revprop svn:log 'New log msg.'
$ svn propget -r foo --revprop svn:log
New log msg.
where 'foo' is a shelf. 'propedit' and 'proplist' and 'propdel' work
too. Only the svn:log revprop is stored in the shelf format so far; it
will be easy to extend to support all revprops.
We may well prefer some other syntax than simply "-r foo", such as "-r
shelf:foo" or "-r [foo]" or whatever, but that's not the main point.
The main point is how the rev spec is converted to an (extended)
svn_opt_revision_t object and then passed in to the libsvn_client APIs,
and to what extent we would need to modify the APIs to properly support
this. Already I found, for example, that the revprop APIs take an
svn_opt_revision_t structure as input but they also output a plain
svn_revnum_t to tell what number a date or 'head' revspec was resolved
to; with a shelved change, the output revision specifier cannot be
represented as svn_revnum_t, and I set it to -1 which causes some ugly
output:
$ svn proplist --revprop -r foo
Unversioned properties on revision -1:
svn:log
So we would want to change this to svn_opt_revision_t. This is just the
first example I have come across of a change needed; some other APIs
will likely require more extensive changes.
Only revprop access is implemented so far, as it was the easiest part to
implement. Providing unified access to a 'tree snapshot' view of the
shelved version (svn list/cat/propget (versioned properties), etc.) and
making modifications (svn add/cp/mv/rm/propset, etc.) and a 'difference'
view (svn diff/status) will be cumbersome to implement, especially with
patch file as the storage, although relatively straightforward in
principle. This could be the trigger for a change in storage form.
- Julian
