Testing an RC of evolve 11.0.0 and topic 1.0.0

Georges Racinet georges.racinet at octobus.net
Mon Feb 13 17:40:53 UTC 2023


Hi Anton,

On 1/30/23 16:24, Anton Shestakov wrote:
> We're planning to release a feature release candidate of evolve and 
> topic extensions that contains an implementation of a concept that was 
> in the plans for quite some time: topic namespaces (the name could 
> change, if we find something better) 
> https://www.mercurial-scm.org/wiki/TopicPlan#sub_branches.2C_namespacing_and_representation

I'm glad to see topic namespaces going forward, since they will be an 
important part of user experience improvements in Heptapod (drive-by 
contributons, notably). I have a few questions.

>
> In short, topic namespaces are trying to fix one of our major UX 
> flaws: branches can continue to be used for release management, and 
> topics can still be used for implementing features, but now there 
> would be something for organizing topics into wider concepts. Topic 
> namespaces, just like topics, are designed to go away when you publish 
> your commits, and we tried to make them as unobtrusive as possible, to 
> not get in the way of current workflows. There is a default topic 
> namespace that will not clutter the UI, and users can keep using only 
> branches and topics as usual.
>
> But we did change some things in the UI. Remember seeing 
> "branch:topic" format in `hg branches`? Well, it was a temporary 
> implementation detail. With the implementation of topic namespaces we 
> introduce a more thought-out way to represent branches plus topics. In 
> this new format, topic namespaces become sort of a glue for all things 
> related to (named) branching, e.g. this is what you'd see in hg log:
>
>   branch//namespace/topic
>
> or, if you don't set topic namespace:
>
>   branch//topic

Internally, Heptapod relies on the `branch:topic` syntax, more 
specifically as keys in the branchmap. Well, it relies on lots of 
Mercurial and evolve internals (I dare not say APIs).

The good news here is that simply replacing `:` with `//` makes all the 
tests pass. Given the full coverage, I'm fairly confident that there are 
no other problems, as far as we're only talking about the compatibility 
itself with (server-side) Heptapod.

Overall it looks like an unnecessary complication to try and support 
both syntaxes in Heptapod. I'm more comfortable keeping my compatibility 
fixes around and making the switch once Evolve 11.0.0 is released.

My questions:

- will there be in 11.0 a way for clients to specify topic namespaces? 
I'd like to test what will happen if some client sends namespaced topics 
to the server before it is fully ready to interpret them (i.e. map them 
to the permissions model).

- what will happen when topic namespaces are fully implemented and users 
with, say hg-evolve 12.0, push to a server with hg-evolve 10.5? Can I 
simulate that from a Python interpreter already?

- will 11.0 be required to support the upcoming Mercurial 6.4?

Best,

-- 
Georges Racinet
https://octobus.net, https://about.heptapod.host, https://heptapod.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics



More information about the Mercurial-devel mailing list