Johan, thank you very much for these considered thoughts!
Johan Corveleyn wrote:
> First of all: thanks for working on shelving and checkpointing,
> Julian. These could become very important and big features. Daunting
> to take them on, but it's good to see someone having a go at it.
>
> I've tried to read through all the docs and recent mail threads. Below
> are a couple of thoughts.
>
> TL;DR: I'd suggest first going for a very good Shelving
> implementation, and not rushing for Checkpointing. Shelving can
> already solve some checkpointing use-cases (see below), and
> Checkpointing as a full-blown feature needs very careful thought (even
> if limited, it's risky to paint ourselves into a corner), and will
> quickly raise expectations of "local commits" or "local branching"
> (which still seem far away).
Agreed.
> == Shelving ==
>
> Looks great so far. Of course a lot of challenges remain for all the
> cases which are not yet (correctly) covered by 'svn diff' and 'svn
> patch' (property changes, tree operations, binary files, unresolved
> conflicts, etc.). Attaching a log message to a shelf is key, and the
> association with changelists looks like a good approach.
>
> - Shelves should (eventually) support directories as "versioned
> items". Changelists currently don't support directories.
I agree with all this too. A log message is supported in the prototype
(but not yet integrated with changelists, as discussed in another thread).
> - Suggestion: 'svn shelve --keep', to create a shelf (patch) in the
> "shelf storage" but not revert it. That would enable some crude way of
> checkpointing your work, through simple patches (which can be applied
> later by fuzzy patching, or ...):
>
> work on feature A
> svn shelve --keep --name "feature A"
> continue work on feature A
> turns out badly, lets go back
> svn revert; svn unshelve "feature A"
Yes; implemented now in r1806168.
In fact this usage aligns very well with how I use patch files myself. I
often save a series of patches to checkpoint my development of a
feature, with names like 'foo-1.patch' ... 'foo-N.patch'.
One thing I like to do in that case is to copy the log message from the
top of the previous patch into the top of the new patch and update it.
If Subversion could make that step easier, that would help.
At present the prototype 'svn shelve' accepts a log message with '-m'
or'-F' but doesn't provide an easy way to invoke an editor, assuming you
don't want a log message if you don't specify one. One way to solve that
would be by adopting the same convention as 'commit': pop up an editor
by default and allow quitting with an empty message if desired. Another
way could be a command-line option if we think no-log-message use cases
should be the default. But that's a UI detail that we can leave till later.
The Checkpoint feature could add the copy-and-modify facility for the
log message.
> == Checkpointing ==
>
> I think only "option 3" looks viable / interesting in the long run
> (option 1, storing patches, looks a lot like simple shelving, so not
> much more value imho). Or even a completely different approach which
> is implemented in working copy storage (option 4? I haven't thought
> this through, but I'm afraid of the disk space requirements, and init
> I/O cost, of option 3 for large multi-GB working copies).
>
> It's very hard for me to not think of checkpoints as local branches of
> some sort. And my users will immediately want to use them in that way.
> In all honesty, I think we should aim for powerful local branches (and
> think of an architecture / design / ui for that), and then think about
> how we can perhaps start with something simpler and more limited as a
> first step, but which goes in that direction. I.e. a more holistic
> design around "local branches", "local commits", "checkpointing".
> What's the big picture?
Good question. While I am continuing to think about ways in which some
larger scope towards "local branching" could play out, I don't currently
see that ever working well for Subversion, at least not the current
generation 1.x.
Given your comments about shelving being almost enough, I now wonder if
we should design simple checkpointing as a simple extension to shelving,
whereby we:
* automatically increment the patch suffix number,
if the latest shelved patch was made with '--keep-local';
* also transfer the log message transfer from the previous numbered
patch and offer it for editing;
* offer a UI shortcut to revert to the previous version in the series;
and any other similar things.
WDYT?
> - After reading the "Terminology" section of
> https://wiki.apache.org/subversion/SavePoints, I agree with that
> document that "Savepoints" might be a better name. But don't want to
> bikeshed over it ...
Could be. (Also, 'checkpoint' is similar to 'checkout' which makes
command-line completion not work well, and the possible abbreviation
'cp' clashes with 'copy'.)
> - In a prior mail-thread between you and Nathan Hartman the "rebasing"
> problem was mentioned. In [1] you said:
>
>> Performing an 'update' with a checkpoint series is a bigger ask than it
>> might at first seem. In effect, it requires rebasing the series of
>> checkpoints on the new base, which gets ugly because of the need to
>> handle conflicts (which is ugly enough already in the existing
>> single-depth WC).
>
> However, that seems to only sane way to go for me. Rebasing the
> checkpoints one by one, and resolving conflicts along the way. Don't
> know how you'd do that though, if the checkpoints are revisions 1, 2,
> 3 in a local repository (with immutable history etc). This is really
> something where the "local repository" technique breaks down IMHO. In
> contract with DVCS's, in SVN history is immutable. But mutability is
> quite important for local branches / commits.
Yes, I have realized that it is going to be tricky to make storage in a
local repository effectively mutable. There are various options, the
most plausible being to leave old data in place and keep committing the
modified versions of changes, tracking them as needed; but it's not simple.
> In that sense, a series of patches is more flexible: you can still
> apply them with fuzz even if applying them to a different BASE state,
> and often that will "just work" (and conflicts "just" need to be
> resolved).
I don't buy that as an easier solution to updating a patch series. Any
conflicts would be handled worse this way.
> In that light, Nathan's latest post in that thread ([2]) was also
> interesting, where he suggested to store the BASE together with the
> WORK for every checkpoint. I'm not sure if that's the way to go (maybe
> you only need a "description of BASE", not the pristines etc), but it
> made me realize: don't expect checkpoints to work for "undo 'svn
> update'" if you can't restore the original BASE tree (down to the
> exact mixed-revisionness).
Yes... I haven't digested and replied to that yet but I intend to.
> [1] https://svn.haxx.se/dev/archive-2017-07/0302.shtml
> [2] https://svn.haxx.se/dev/archive-2017-08/0064.shtml
Very productive. Please don't hold back on further thoughts!
- Julian
Received on 2017-08-25 15:33:17 CEST