subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject Re: [RFC] Shelving and Checkpointing
Date Mon, 24 Jul 2017 14:34:15 GMT
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

View raw message