On Fri, Aug 25, 2017 at 3:33 PM, Julian Foad <julianfoad_at_apache.org> wrote:
...
>> == 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).
We'll need to have the discussion about what changelists should do
with directories though. Not sure what prior discussions were already
held about this, when the changelist feature was designed ...
>> - 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.
Great!
> 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.
Yes, maybe we'll need to have some grouping structure / namespacing in
the shelves for this. A "rack" or something :-). The rack carries a
name ("savepoints", "feature A"); a single shelf in a rack is just
'svn shelve --rack "feature A"'; If I add more shelves to a rack, they
get numbered.
svn shelve --keep-local --rack savepoints -> shelf "savepoints-0" (or
just "savepoints"?)
svn shelve --keep-local --rack savepoints -> shelf "savepoints-1"
svn revert
svn unshelve savepoints-0
Just thinking out loud here ...
>
>> == 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?
Yes! I think that would be enough for a good release 1.11, with nice
"shelving" and basic checkpointing (actually mainly UI lipstick with
options / conventions on the "shelve / unshelve" commands) on top of
it. Leaves the door open for more fundamental things in the future ...
>> - 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.
Okay, updating the patches when the "new base" comes in might indeed
be better. OTOH: if the user has discarded / forgotten about his
checkpoints, any "early conflict resolution of checkpoints / patches"
might be a waste of time. It's a tradeoff I guess (perhaps updating
them should be done "during rebasing", but the user can postpone
conflicts ...). And what if rebasing checkpoint-2 has a conflict, but
that conflict would not occur when rebasing checkpoint-3 (i.e. a
change was made locally which eliminated the conflict)? Hmmm ...
--
Johan
Received on 2017-08-25 16:10:25 CEST