[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Shelving and Checkpointing support log messages

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 25 Aug 2017 11:29:54 +0200

On Fri, Aug 25, 2017 at 11:08 AM, Julian Foad <julianfoad_at_apache.org> wrote:
> 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.)
>
> Example workflow:
>
> 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:
> https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#heading=h.ay5h5pfumpv8
>
> What do you think?

+1, that looks like a good approach.

In the google doc you mentioned some issues with this:

* a changelist can include unmodified paths
  should a shelved patch also include unmodified paths?

-> I guess that would be the best solution for this. The shelve should
keep (in metadata) a list of paths that were part of the changelist.

* a path can appear in multiple shelves, but only in one changelist
  what to do when unshelving if a path clashes?

-> Hmm, that's a hard one. No idea for now, except perhaps extending
changelist to make it possible for paths to be part of multiple
changelists too.

FWIW: IntelliJ IDEA gives you a warning when you start editing a file
that's part of some changelist, while your default changelist is set
to another changelist ("File from non-active changelist is modified").
The user can "Move changes", "Switch changelist" or "Ignore" (though
it's not clear to me what "Ignore" does ... the file doesn't become
part of the "active changelist" suddenly, or of both, so this seems
equal to "Move changes").

* any extensions should apply uniformly to both shelving and changelists
  if a shelved change supports a log msg, a changelist should support
a log msg too; this would be a good enhancement for changelists anyway
even without shelving

-> Yup, sounds good to me :)

I see one more important caveat: changelists currently don't support
directories as members.

I have some more thoughts on shelves and checkpoints, but I'll put
them in a separate thread.

-- 
Johan
Received on 2017-08-25 11:30:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.