Testing an RC of evolve 11.0.0 and topic 1.0.0

[Anton Shestakov]

Hello, users of Mercurial, Evolve and/or Topic!

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

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

In the future, we're going to support providing branches, topic 
namespaces (if you decide to use them) and topics in this format to all 
commands where it makes sense.

Now, what these topic namespaces are aimed at? Among other things, topic 
namespaces are supposed to help users manage topics; their own and other 
users'. Previously, some people were already using username as a prefix 
for their topic names - this was an ad-hoc implementation of separation 
and/or ownership of work, and now with topic namespaces it's becoming 
more standardized and user-friendly.

Here are more details on what aspects of workflow topic namespaces try 
to improve (taken from the wiki page linked above):

* on the client side, they could be used to safeguard history-rewriting 
operations and in particular avoid conflicting with other people's work

* code hosting providers and forges could map topic namespaces to their 
user or team concepts, and hence ultimately to their permission model

* they could be used to narrow user view and exchange to the part that 
are relevant to them by default

Although the UI didn't change much, and a big part of the planned 
features is not implemented yet, the changes that are included are quite 
extensive. We have changed a significant part of topic's representation 
locally and over the wire during the exchange. Given the scale of these 
changes we encourage people to test this release candidate. That would 
definitely help us pinpoint real issues that we didn't foresee during 
the planning and the development. It could also possibly give you some 
ideas how to integrate topic namespaces into your workflows early.

The release candidate is coming out in the next few days, and the final 
feature release will most likely be ready in about 2 weeks after that. 
During these 2 weeks you can reach out to us and tell if you notice 
something being broken, and we'll obviously try and fix it before the 
final release. That being said, topic namespaces are here to stay, 
although maybe under a different name and with some changes after 
testing in real circumstances.