Recent evolve --all changes
Josef 'Jeff' Sipek
jeffpc at josefsipek.net
Mon May 6 15:14:26 UTC 2019
On Sun, May 05, 2019 at 20:12:13 +0200, Pierre-Yves David wrote:
> On 5/4/19 4:39 AM, Josef 'Jeff' Sipek wrote:
> > On Fri, May 03, 2019 at 00:04:01 +0200, Pierre-Yves David wrote:
> >> On 4/29/19 10:32 PM, Kyle Lippincott wrote:
> > ...
> >>> I believe `hg next` will automatically evolve now, so that might be
> >>> sufficient for your use case?
> >>
> >> Yes, the recommended way to stabilize your children on at a time is `hg
> >> next`. I has been the "official" way to do so for a couple of version.
> >
> > It took me a couple of days to fully exercise 'hg next'. Indeed that does
> > what I wanted.
>
> Happy to see that the replacement is suitable
I just hit a scenario where I'm not sure what to use (short of 'hg evolve
--no-all').
Suppose I have this sort of DAG in a repo on two hosts:
A -> B -> C
And I run:
hostB$ hg up B
hostB$ echo foo > something
hostB$ hg amend
hostA$ hg up B
hostA$ hg bookmark book
hostA$ hg pull hostB
At this point, I used to use 'hg evolve' to (1) stabilize the bookmark, (2)
update to the stable cset, but (3) leaving C alone in need of stabilization.
With the new behavior, I seem to have 4 choices:
hostA$ hg evolve --no-all # ok, but lots to type
hostA$ hg evolve # tries to stabilize C == not desirable
hostA$ hg next # doesn't stabilize, only updates wdir
hostA$ hg up Bnew && hg bookmark book # urgh
Sure, I could set up an alias for 'hg evolve --no-all', but since
incremental stabilization is supposed to be a first class concept, it seems
like the evolve extension should come with an easy way of doing that without
hgrc tweaks.
(The actual scenario involves hg-git making bookmarks, but me not
propagating them to the (hg) clone of the repo on my dev box.)
> > Was this change communicated to the users? It should have been. It's
> > possible that I just missed it. :)
>
> This kind of changes areusually mentionned in the release announcement
> for a previous version. In this case the change to --all is
> pre-announced here
> https://www.mercurial-scm.org/pipermail/evolve-testers/2019-April/000366.html
>
> The new behavior is not released yet. So it will be part of the new
> release changelog.
Ah, I guess I just missed it. (Yeah, I know... running the latest and
greatest revision means I get to "suffer" with BCs earlier than other
people.)
> >> (Yes I understand existing user need to be retrained)
> >>
> >> I am still recommending incremental stabilization, for your day to day
> >> workflow, the interface to do this just shifted to `prev/next` (and
> >> checkout `hg stack` from the topic extensions too). Evolve move to be a
> >> more "secondary" command more focused on dealing with consequences of
> >> exchanging draft, and less about stacked draft local workflow.
> >
> > Makes sense and I'm fine with this behavior change. It just caught me by
> > surprise with no indication what the "proper" way to do incremental
> > stabilization was.
>
> We probably need to rework evolve help to make it clearer and point to
> `hg next`. Do you want to give a stab at doing so?
Normally I would, but I know that the next month and a half will be way too
busy for me as is and so I shouldn't sign up for more todo items.
Jeff.
--
Intellectuals solve problems; geniuses prevent them
- Albert Einstein
More information about the Evolve-testers
mailing list