Julian Foad wrote:
> [[[
> $ svn savepoint log 'qq'
> version 1: 52 days ago
> 0 files changed
>
> version 2: 51 days ago
> hello.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> version 3: 32 days ago
> D5/file | 2 ++
> hello.txt | 1 +
> 2 files changed, 3 insertions(+)
>
>
> $ svn savepoint restore qq 2
> U hello.txt
> restored 'qq' version 2 and deleted 1 newer versions
>
> ]]]
>
> Now I'm talking about *syntax* for accessing these.
Shelved changes are parallel to working changes.
WC-base
\ \ \ \__ WC-working
\ \ \__ shelf 'foo' v1
\ \__ shelf 'foo' v2
\__ shelf 'bar' v1
The 'working' state and each 'shelved' state can be considered as a tree
snapshot, and can also be considered as a diff relative to WC-base. In
the near future hopefully we'll be able to track a different base for
each shelf-version; for now they are all (implicitly) considered
relative to the current WC base (even though the patch files already
contain the base revision number of each file; currently we ignore those).
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:
WC-base svn_opt_revision_base "-r BASE"
\ \ \ \__ WC-working svn_opt_revision_working (no CLI syntax)
\ \ \__ shelf 'foo' v1
\ \__ shelf 'foo' v2
\__ shelf 'bar' v1
(svn_opt_revision_working, _base, etc.).
We could extend the revision specifiers to refer to shelved versions:
WC-base {svn_opt_revision_base}
\ \ \ \__ WC-working {svn_opt_revision_working}
\ \ \__ shelf 'foo' v1 {svn_opt_revision_shelf,'foo',1}
\ \__ shelf 'foo' v2 {svn_opt_revision_shelf,'foo',2}
\__ shelf 'bar' v1 {svn_opt_revision_shelf,'bar',1}
with CLI syntax for example:
svn cat -r shelf:foo path/to/file
svn cat path/to/file_at_shelf:foo
svn diff -c shelf:foo
The big advantage of some (any) such scheme is that existing
libsvn_client APIs for operating on a working copy change or state (such
as cat, diff, status, prop*, revprop_get, revprop_set, etc.) can then
potentially be extended to support operating on a shelved change or
state without any change to the API function declaration itself.
Just letting you know where my thoughts are going.
- Julian
Received on 2018-01-09 14:31:54 CET