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
