subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@apache.org>
Subject Re: A rational svn shelve/checkpoint CLI
Date Tue, 09 Jan 2018 21:30:20 GMT
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

Mime
View raw message