Convenient metaedit
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Sun May 5 19:00:38 UTC 2019
On 5/3/19 4:20 AM, Matt Harbison wrote:
> On Thu, 02 May 2019 17:59:12 -0400, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>
>>
>>
>> On 4/27/19 9:16 AM, Friedrich Hagedorn wrote:
>>> Hello,
>>> I tried the metaedit command from the evolve extension and was happy to
>>> find a nearly convenient way to refactor the commit messages of my
>>> recent commits. In order to metaedit the changesets with branched
>>> ancestors together with an unclean work directory I need to do the
>>> following steps:
>>> hg metaedit -r -4
>>> hg shelve
>>> hg hg evolve -aA
>>> hg unshelve
>>> Is it possible to include the last three steps into metaedit? This
>>> would
>>> be really convenient!
>>
>> Yes, meta edit could be working fulling in-memory and skip the
>> requirement for a clean working copy.
>>
>> Can you file a bug at https://bz.mercurial-scm.org/ ?
>>
>> However, we don't usually do automatic evolution of the orphan created
>> by an evolution command. Stabilizing change on demand reduce the
>> amount of markers created. Out of control marker creation can become
>> an issue for very large stack.
>
> Is it useful to do in-memory metaedit, if it didn't automatically
> restack? I thought `hg evolve` complained if there's a dirty wdir. The
> phab extension does this with a couple lines of code, but it gets weird
> if there were unstable descendants at the start.
>
> Even though there are performance issues for creating a lot of markers,
> I wonder if it would be a good idea to have a config option to restack
> by default for new users. I showed someone the help document and
> explained how amend + push could help simplify some CI config testing.
> The response from reading the help that I got was "that seems too
> complicated". So if there's a way to get new users the ability to
> metaedit or amend something that's not a head, without having to teach
> about unstable right away, that might be a good thing.
The main issue is so much raw performance, but fundamental scaling. We
know there are a lot of room to speed up current obsolescence related
operation. I am not opposed to automatic stabilization as long as we get
the scaling concerns under control.
If we do automatic stabilization, a script editing all items in a stack
of N changeset will create N²/2 changesets. The O(N²) aspect creates
scaling concerns. As a reminder here how the N²/2 looks like for a
couple of concrete value
2 → 2 markers total ( 1.0 per changeset)
4 → 8 markers total ( 2.0 per changeset)
5 → 12 markers total ( 2.4 per changeset)
10 → 50 markers total ( 5.0 per changeset)
20 → 200 markers total ( 10.0 per changeset)
30 → 450 markers total ( 15.0 per changeset)
50 → 1250 markers total ( 25.0 per changeset)
200 → 20000 markers total (100.0 per changeset)
To provide more numbers: 10 or 20 is a common stack size, and we
regularly see people building stack in the "hundreds of changesets"
range. And so far, I usually see an average of 10 markers per changesets
at the end of series with a lot of rework. (So adding even 10
marker/changesetswith a single operation has a significant impact).
My most important source of concerns here are basic users with hundreds
of draft that would routinely run commands that seems harmless but
actually creates hundreds of markers, creating a scaling ticking bomb.
That would be bad for both the user and the project.
This does not mean we should (and will) never do some automatic
stabilization. We just need to find a way to do it that avoid being
problematic.
My current best idea on that front is to only perform automatic
stabilization for small enough group and to issue a message pointing to
a help section that explains how to stabilize them and why it was not
done by default. Some work on markers "grouping" could also be explored.
This is far from ideal, but this is a way forward. If others spend some
time on the matters, better alternative can likely be found.
Cheers,
--
Pierre-Yves David
More information about the Evolve-testers
mailing list