subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Hartman <>
Subject Re: [RFC] Shelving and Checkpointing
Date Mon, 24 Jul 2017 14:30:13 GMT
On Fri, Jul 14, 2017 at 7:56 AM, Julian Foad <> wrote:
> Diffing checkpoints is quite hard (well, needs a patch-arithmetic library) in this design.
Even just determining whether two patches are "identical". That might be a good reason for
me to try the alternative design "store checkpoints in a local repository" ("option 3") next.

My thinking is that options 1 or 2 will eventually grow into a redundant implementation of
a VCS within svn to handle various revisions of the working copy. That will most likely be
faster to get off the ground, but results in redundant code, or refactoring existing code
to do the patch arithmetic, etc. Option 3 requires reinventing the client outright but gives
more flexibility in the long run.

I was thinking that svn switch needs to be handled, or chaos would ensue if someone does some
work, makes some shelves and checkpoints, and then does svn switch to a different path. A
solution could be to remember the checkout path and revision with each shelve/checkpoint.
If the user performs svn switch and later wants to reinstate a shelved working copy, the client
will notice that it can't be unshelved until the workspace is switched back to the correct
path and error out with a descriptive message. The user will then svn switch to the correct
branch and reissue the unshelve command. The normal rules apply, which mean that if there
are uncommitted changes in the working copy, the user will have to either commit them or shelve
them before performing the svn switch. A --force option could allow the user to unshelve the
work into the wrong path, possibly with conflicts (but maybe this is intentional).

>>> References:
>>>    [1] Shelving-Checkpointing Dev doc. (J Foad)

View raw message