Re: [RFC] Shelving and Checkpointing

On Fri, Jul 14, 2017 at 7:56 AM, Julian Foad <julianfoad_at_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#
Received on 2017-07-24 16:30:25 CEST