Checkpointing - is not Quilt

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

Initially I wrote that 'checkpointing' should allow committing the 
result either all at once or as a corresponding series of commits. 
Having thought more, I believe the use case for a series of commits 
falls out of scope.

Definitions:

   Quilt:

     Preparing a series of patches that will be applied (perhaps 
committed) sequentially in a given order.
     Each patch represents a self-contained logical change, likely with 
its own log message.
     Later patches may depend on earlier ones.
     Ability to jump to any patch in the series and modify it in the 
context of the earlier patches having been applied and the later ones not.
     After such a modification, updating (as in rebasing) the later 
patches accordingly.
     Ability to commit the series as a corresponding series of commits, 
or all in one commit.

   Checkpointing:

     Saving intermediate, unfinished, working states during the 
preparation of a single logical change.
     The change will be committed as one revision when finished.
     Changing a state that has been checkpointed may be accomplished 
either by rolling back to an earlier state and then re-doing all 
subsequent changes in the desired way, or by leaving that checkpoint in 
place and making a further checkpoint after changing the working state 
in the desired way.
     Like an "undo stack", with or without "redo".


- Julian

Re: Checkpointing - is not Quilt

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

Branko Čibej wrote:
> In order to use checkpoints as a sort of local commit, you do have to be
> able to push a series of commits to the server. You'd distinguish
> explicit checkpoints (with log messages) and implicit/automatic
> checkpoints; only the explicit ones would constitute separate commits.

That would be lovely. It is beyond what I see as basic checkpointing 
functionality (which is more like a local 'undo' mechanism while 
composing one commit).

> In order to support that, you'd have to have a way to rebase the whole
> checkpoint stack onto current HEAD (or at least to a non-conflicting
> state). Ideally you'd also support operations such as checkpoint
> reordering, (local) squashing, removal, etc.

Yes. I'll aim to design in such a way as to make those kinds of things 
possible in future extensions.

I like the idea of being able to have both explicit and 
implicit/automatic/lightweight checkpoints and distinguish them. The 
more I think about automatic checkpoints, the more I see this as 
bringing to Subversion's WC the 'auto-save' and 'undo' features that 
nearly all user-friendly editor applications offer. I can see a GUI 
wanting to make frequent automatic checkpoints so that the user doesn't 
have to remember to do so.

- Julian

Re: Checkpointing - is not Quilt

[Branko Čibej <br...@apache.org>]

On 17.07.2017 13:42, Julian Foad wrote:
> Initially I wrote that 'checkpointing' should allow committing the
> result either all at once or as a corresponding series of commits.
> Having thought more, I believe the use case for a series of commits
> falls out of scope.
>
> Definitions:
>
>   Quilt:
>
>     Preparing a series of patches that will be applied (perhaps
> committed) sequentially in a given order.
>     Each patch represents a self-contained logical change, likely with
> its own log message.
>     Later patches may depend on earlier ones.
>     Ability to jump to any patch in the series and modify it in the
> context of the earlier patches having been applied and the later ones
> not.
>     After such a modification, updating (as in rebasing) the later
> patches accordingly.
>     Ability to commit the series as a corresponding series of commits,
> or all in one commit.
>
>   Checkpointing:
>
>     Saving intermediate, unfinished, working states during the
> preparation of a single logical change.
>     The change will be committed as one revision when finished.
>     Changing a state that has been checkpointed may be accomplished
> either by rolling back to an earlier state and then re-doing all
> subsequent changes in the desired way, or by leaving that checkpoint
> in place and making a further checkpoint after changing the working
> state in the desired way.
>     Like an "undo stack", with or without "redo".


In order to use checkpoints as a sort of local commit, you do have to be
able to push a series of commits to the server. You'd distinguish
explicit checkpoints (with log messages) and implicit/automatic
checkpoints; only the explicit ones would constitute separate commits.

In order to support that, you'd have to have a way to rebase the whole
checkpoint stack onto current HEAD (or at least to a non-conflicting
state). Ideally you'd also support operations such as checkpoint
reordering, (local) squashing, removal, etc.

-- Brane