What can we learn from this mock-up? Here are some of my thoughts.
* Status and diff against last incremental change vs. against the
'commit base'.
* The 'init' and 'finish' work flow should be simpler.
* s/w architecture: exporting from WC, changing the WC base, ...
== Status and diff against last incremental change vs. against the
'commit base'
If I checkpoint my changes, do I then want to see 'status' and 'diff'
against the original base or against the checkpoint? Both are useful.
This is completely analogous to working on a branch. Sometimes I want to
review just my latest change on the branch, and sometimes I want to
review what I have changed in total on the branch, in other words what I
will be merging back to the parent branch. In this regard, checkpointing
is like a local branch.
For backward compatibility with Subversion's user interface, we have to
choose one base or the other as the 'default' diff/status base. Ideally
we will make both bases support exactly the same enquiry features, and
the selection of the default base will be merely a user-interface
convenience.
(Long ago I drafted a patch to make it easy to run a diff against the
merge base, when working on a branch, because doing this useful task
manually was fiddly. The UI looked like 'svn diff --against-merge-base'
or some such option, nothing more needed to be specified, and it invoked
the merge base-finding code and then ran a diff against the found base.)
Diff and status are the obvious commands which compare against a base,
where choosing the base will be appropriate. I need to check what other
commands it might also apply to.
Commands that run back through history, especially 'log' and 'blame',
also need some adjustment. In the mock-up right now, these just report
what is in the local repo. We might instead prefer 'log' and 'blame' to
show revisions from the original repository (assuming it's online), so
they keep their original meaning and ignore checkpoints. Or we might
prefer them to show both the checkpoints and the original repository
revisions.
== The 'init' and 'finish' work flow should be simpler.
Probably 'checkpoint init' should not be needed, and instead running
'checkpoint save' should initialize the checkpointing repo if not
already done.
Probably 'checkpoint finish|uninit' should not be needed, and instead
should happen automatically when the user either commits or reverts the
entire set of changes.
The 'checkpoint squash' command is provided only for experimentation.
Squashing back to a plain WC with local mods is something that happens
as part of 'finish', and would be needed within a future 'checkpoint
commit' that commits everything in one revision. I don't think it is
needed separately.
== s/w architecture: exporting from WC, changing the WC base, ...
Some APIs that would be useful do not currently exist.
First, I wanted to copy the WC base into a new repository. Ideally the
WC will expose standard 'editor' API to export the base, and we would
pipe this into a commit editor. At the moment, the 'export' command
instead uses the WC's 'walk status' API with a set of callbacks that
write the exported data onto disk, where as 'export' from a repository
uses a standard 'editor' with a different set of callbacks that write
the exported data onto disk.
The 'squash' code is implemented by updating the WC back to r1 in the
checkpoints repo, and then merging all the checkpoints repo content
(r1:HEAD) into the WC working state, without mergeinfo. Instead, it
would be nice to have an API that directly updates the WC base back to
r1 while adjusting the 'scheduling' of each path (add/del/modify) so as
to keep the WC working state constant. (That is, 'rebasing' the WC.)
Your thoughts, anyone?
In particular, how well is the work flow shaping up, if we assume we
will eliminate the 'init' and teach 'revert' and 'commit' to do the
'finish' actions automatically?
- Julian
On 26/07/17 16:13, Julian Foad wrote:
> I committed an initial prototype for checkpointing backed by a local
> repo embedded in the WC (the "option 3" design), on the
> "shelve-checkpoint3" branch.
>
> http://svn.apache.org/r1803046 and follow-ups.
>
> Here is the help output:
> [[[
> $ svn checkpoint --help
> checkpoint: Checkpoint the local changes.
> usage: 0. checkpoint init
> 1. checkpoint save
> 2. checkpoint revert
> 3. checkpoint rollback NUMBER
> 4. checkpoint list|log
> 5. checkpoint squash
> 6. checkpoint finish|uninit
[...]
>
> If you read this far and get a chance to try it out, I'd love to hear
> your thoughts on the overall shape and the big-picture possibilities. (I
> am not so concerned about details at this stage, but mention those too
> and hopefully they will spark further thoughts.)
Received on 2017-07-27 13:56:10 CEST