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.)
