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@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

Reply via email to