Daniel Shahaf wrote:
> Julian Foad wrote on Thu, 24 Aug 2017 19:46 +0100:
>> One rough edge is that "unshelving" a patch or finishing/squashing a
>> checkpoint series simply discards the log message(s). [...]
> [...] to enable the "long log message" use-case, there should be an easy
> "upgrade path" for the shelf's log message to become a commit log message;
> optionally with editing first.
> Example workflow:
> 1. There exists a shelf with a verbose log message
> 2. Unshelve that patch
> 3. 'make check'
> 4. 'svn commit'
> In this workflow, it would be nice for $EDITOR to be pre-filled with the
> shelf's log message.
> The catch is, what happens if the patch is reverted [...] step #4
> doesn't know whether it's committing the patch that had been
> unshelved, or something else [...]
A neat solution could be to integrate Shelving with Changelists in such
a way that Unshelving means converting a patch to a changelist, and a
changelist grows support for storing a log message.
This would be a two-way integration: shelving a changelist would then
mean converting the changelist to a patch and reverting the changelist
from the WC.
This would be more in line with how, for example, Perforce defines a
changelist: there it is a change, whether committed or shelved or in one
or two other states; and includes a log message and some other metadata.
(In fact, right from when we introduced "changelists", I have wanted
them to support storing a log message, without even thinking about the
possibility of shelving.)
1. There exists a shelved patch 'foo' with a verbose log message
2. 'svn unshelve foo'
3. 'make check'
4. 'svn commit --changelist foo'
In this example, the unshelve creates & populates changelist 'foo', and
the commit takes its log msg from changelist foo.
To me this seems very appealing.
I outlined this idea in the section "Integrate Shelving with
Changelists" in the "Shelving-Checkpointing Dev" doc:
What do you think?
Received on 2017-08-25 11:08:11 CEST