Hi Nathan. Thanks for your thoughts.
Nathan Hartman wrote:
> 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.
Yes, this is a serious consideration. Re-using the repository design
gives not only flexibility but the reliability and maintainability that
comes from sharing a single implementation of the functionality (DRY). I
am going to look further into this approach next.
> 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.
It's not extremely unusual to want to apply some changes onto a
different branch, but I agree it's probably best to record the base path
used, and for the 'svn' CLI to assume this might be a mistake and so
warn or error and require 'force' to unshelve to a different path. (A
more interactive client could offer a better UX.)
I have now listed this suggestion under 'extensions', and promoted
'recording the base state' into the 'good usability' column of the table
rather than 'no'.
> 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.
> [...]
Actually, 'switch' normally allows uncommitted changes in just the same
way that 'update' does.
- Julian
