On Fri, Jul 14, 2017 at 7:56 AM, Julian Foad <julianf...@apache.org> 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)
>>> https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#
>>>
