How should shelving interact with checkpoints?

[Julian Foad <ju...@apache.org>]

I have been thinking about, and written [1], the following:


How should shelving interact with checkpoints?

In other words, what do we expect to happen if we start working, make
some checkpoints, and then shelve "the work" to work on something else?
Do we usually want to shelve the whole series of checkpoints, or just
the latest (uncheckpointed) working change and start new work against
the latest checkpoint?

If the checkpointing design shows WC state relative to the latest
checkpoint (as in option 3), then shelving should:

  * Shelve the (uncheckpointed) working change, leaving all checkpoints
as they are.

This returns the WC to showing an unmodified state relative to the
latest checkpoint.

If the checkpointing design shows WC state relative to the original base
(as in option 1), and checkpoints exist, then shelving should:

  * Shelve the working change and restore the latest checkpoint.

In this case, since the working change is based on the original base,
the resulting patch includes the changes made in all the earlier
checkpoints. The effect is like making a more permanent kind of
checkpoint that is tagged with a name and will survive rollbacks.

Other possibilities that I thought about and rejected were:

  * Warn and/or require user input; then discard (squash) checkpoints
and shelve a single patch.

  * Save the whole series of (N) checkpoints and working state, e.g. as
'foo-1.patch' ... 'foo-N.patch', 'foo.patch'. In that case, unshelving
while some (M) checkpoints already exist would perhaps add 'foo-1.patch'
as checkpoint(M+1) ... 'foo-N.patch' as checkpoint(M+N), 'foo.patch' as
the new working state. But then what? Too messy.


That seems good to me. Any other thoughts?

- Julian


[1]
https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#heading=h.ilq1gee589ue