Which parts of Evolve can be upstreamed?

[Pierre-Yves David]

On 2/11/21 11:54 PM, Martin von Zweigbergk via Mercurial-devel wrote:
> On Mon, Feb 8, 2021 at 11:28 PM Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>>
>> The short answer is:
>>
>> They are comment in multiple source files about their status and the
>> part that can be uptreamed.
>>
>>
>> For a longer answer I need to double check my notes.
>> On a general basis :
>> - The user facing command is the most "mutable" part that we will likely
>> keep experimenting for a while.
> 
> Sure, they may always change a bit, but I think obslog and prune have
> been quite stable for a while.

The obslog command is in a good shape, the extensive rework done in 
2020, has been completed and properly validated with users. That is a 
good candidate for upstreaming. I am fully supporting of moving that 
code upstream.

Regarding prune, however, that is premature. `The "core" set of history 
editing command provided by evolve is not stable and expected to need 
significant rework and user testing (including on older Mercurial 
version). In 2020 we actually got a batch of new feedback about `hg 
prune` that we will look into within 2021. So, as the current maintainer 
of evolution, including the `hg prune` command, I want it to stay within 
evolve for now, and I don't approve upstreaming it yet.

> I know that the obslog output was
> changed quite a bit recently, but that change could have been done in
> core instead if it had been there.

Actually, no it could not. [putting my "head of Octobus" hat on] The 
overall health of Mercurial core development makes it significantly 
harder to do work there, to the point where multiple people under the 
larger Octobus umbrella have expressed expressed their wish to avoid it, 
even sometimes refusing to do work if it involves core development.


(I hope this does not comes as a surprise to you as I already sent this 
feedback to multiple reviewers/steering-committee members, and I know 
other have tried to alert on various issues too.)


So some of the large work that Octobus funded in evolve in the past 
years would not have happened at all in Mercurial core because they 
would have been significantly more expensive to do, or it would have 
been harder to find someone to do them.


Development also has other reasons for happening in the extension (eg: 
release cycle, compatibility with older version, etc). However since 
this is covered by various documentation and discussed lengthy in the 
past, I won't spend more time writing about it again.

> Maybe I'll start upstreaming the changes to rewriteutil.py that have
> been added in since the last attempt.

This looks like a good idea. rewriteutils.py is a set of utility that 
adds great value to core and is easy to extend from the extension when 
needed. So +1 for that.


> Then I'll see if I can upstream
> the prune command.

So, as pointed above, please look into upstreaming obslog instead.

>> - The latest upstreaming effort was around the stack concept that proved
>> itself central for providing a consistent UX around `hg evolve` in
>> distributed context. I would be happy to see it get to conclusion.
>> - The change to heads computation and checking is a good candidate for
>> upstreaming is all the logic live in core and they "wrapping" in the
>> extension are neither very clean nor performant
> 
> I looked into that a bit. It seems it's used for some
> experimental.single-head-per-branch that I had never heard of. If
> that's correct, it doesn't seem that useful to me at least. If others
> care about that option, they can upstream that part. Correct me if I
> misunderstood what the "heads computation and checking" is about, of
> course.

This is logic related to how we compute heads of branch when 
obsolescence is involved. It is important for people using Mercurial to 
push and pull draft changesets to common servers, something that I don't 
think Google is doing. This is pretty important to provide useful 
workflows to a more generic set of Mercurial users. If you are not 
interested in that, I'll see if I can nerd-snipe Joerg into moving it 
upstream o:-).

>> On 2/8/21 11:59 PM, Martin von Zweigbergk wrote:
>>> Hi,
>>>
>>> We have talked about upstreaming the Evolve extension for years and some
>>> of it has been upstreamed, but most of it remains. I think most of us
>>> agree that it would be good to have it upstreamed at some point. Are
>>> there some uncontroversial parts that I can start moving upstream? The
>>> obslog and prune commands seem like good candidates to me. What do you
>>> think?


-- 
Pierre-Yves David