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