Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
14.02.2023 17:20, Georges Racinet пишет: 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). In 11.0.0rc0+ branchmap will have keys in the "branch//namespace/topic" format. There are more places when you'll see this format instead of branch name alone now and we intend to use it locally more widely in future. 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. Make sure you look though examples for formatfqbn() and parsefqbn() in topic/common.py. 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? There is a debug-topic-namespace command that will let you do it. - 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? Topic namespaces are not understood by older clients, so those clients will simply see branches+topics only. So if you had branch "b", topic namespace "tns" and topic "t", then newer clients would see "b//tns/t", and older clients would see "b:t". It's been deemed to be safe, because the worst case is you're using new version and trying to push "b//foo/t" and older server has "b//bar/t": you won't be able to push freely because server sees them both as "b:t". Simulating locally is not yet possible, but adding that (for testing purposes) is on my plate for the final release. - will 11.0 be required to support the upcoming Mercurial 6.4? Probably not evolve version 11.0.0 specifically, since it's planned to be released before hg 6.4, but we will release a bugfix/maintenance release with support for new versions of Mercurial. So most likely, 11.0.1 will support hg 6.4. Although if we see hg 6.4rc0 soon, then we can support that version in 11.0.0. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
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 ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
30.01.2023 19:24, Anton Shestakov пишет: 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. And after numerous compatibility fixes and tweaks (and some delays) 11.0.0rc0 is finally out! If you want to test it, you might need to specify the new version explicitly to install it, e.g. `pip install hg-evolve==11.0.0rc0`. If you spot any issues with it, feel free to contact the developers in your preferred way (e.g. via bugzilla, #mercurial or #hg-evolve on libera.chat or replying to this email on list or to me directly). ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
>>> "AS" == Anton Shestakov writes: > 04.02.2023 22:56, Uwe Brauer пишет: >> Maybe we have a misunderstanding here. >> I don't mean the result >> hg branches >> I meant that sometimes >> hg log (with my template, I am not going to post here would give >> me) >> ◍ changeset: 674:5c76f339a2eb >> │ tag: tip >> │ Branch:year-2022-23//git-manual >> │ Author:Uwe Brauer >> │ Date: Sat, 04 Feb 2023 18:45:29 +0100 >> │ Topic: git-manual >> │ Phase: draft >> │ Summary: Old text out, tutorias programadas >> │ > Well, this is most likely not done by evolve/topic extensions. As I > said, no released version of evolve or topic uses '//' as a separator > in the UI yet. What's more, even the default branch (not released) > doesn't override `hg log` entries to be in this format. What versions > of evolve and topic are you using, after all? evolve external 10.1.0 topicexternal 0.20.0 > There's one case where topic extension (briefly and internally) uses > '//' to separate branch and topic, and it's used for > experimental.topic.linear-merge implementation. If it's visible in the > UI during normal operations, this could be a bug that needs to be > fixed. Ha, this is it. Basically I nagged so long on the list till Pierre-Yves said it will be implemented. I have activated it and use it from time to time. > However, from what I know now, this really seem to be your custom log > template that's doing it. >> And that I found very annoying. > Why? Because it seemed to pop up for no reason, but you said, most likely I bug. I should upgrade evolve and topics I presume. -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ smime.p7s Description: S/MIME cryptographic signature ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
04.02.2023 22:56, Uwe Brauer пишет: Maybe we have a misunderstanding here. I don't mean the result hg branches I meant that sometimes hg log (with my template, I am not going to post here would give me) ◍ changeset: 674:5c76f339a2eb │ tag: tip │ Branch:year-2022-23//git-manual │ Author:Uwe Brauer │ Date: Sat, 04 Feb 2023 18:45:29 +0100 │ Topic: git-manual │ Phase: draft │ Summary: Old text out, tutorias programadas │ Well, this is most likely not done by evolve/topic extensions. As I said, no released version of evolve or topic uses '//' as a separator in the UI yet. What's more, even the default branch (not released) doesn't override `hg log` entries to be in this format. What versions of evolve and topic are you using, after all? There's one case where topic extension (briefly and internally) uses '//' to separate branch and topic, and it's used for experimental.topic.linear-merge implementation. If it's visible in the UI during normal operations, this could be a bug that needs to be fixed. However, from what I know now, this really seem to be your custom log template that's doing it. And that I found very annoying. Why? ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
>>> "AS" == Anton Shestakov writes: > 04.02.2023 14:56, Uwe Brauer пишет: >> >>> 03.02.2023 00:34, Uwe Brauer пишет: >> >>> By "this" do you mean "branch:topic" or "branch//topic"? >> I meant "branch//topic" >> So can I switch the new namespace feature of, if I don't like it? > That depends on what you think "the new namespace feature" is. If you > don't want to use topic namespaces, then you don't have to. There's a > default namespace that will not be shown (similar to default branch or > empty topic). > On the other hand, if you want to forever use "branch:topic" format > that was never intended to be usable (e.g. hg up "branch:topic" > doesn't necessarily do what you expect), then you can use old versions > of evolve and topic. Maybe we have a misunderstanding here. I don't mean the result hg branches I meant that sometimes hg log (with my template, I am not going to post here would give me) ◍ changeset: 674:5c76f339a2eb │ tag: tip │ Branch:year-2022-23//git-manual │ Author:Uwe Brauer │ Date: Sat, 04 Feb 2023 18:45:29 +0100 │ Topic: git-manual │ Phase: draft │ Summary: Old text out, tutorias programadas │ And that I found very annoying. While hg branches results in year-2022-23:git-manual 674:5c76f339a2eb smime.p7s Description: S/MIME cryptographic signature ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
04.02.2023 14:56, Uwe Brauer пишет: 03.02.2023 00:34, Uwe Brauer пишет: By "this" do you mean "branch:topic" or "branch//topic"? I meant "branch//topic" So can I switch the new namespace feature of, if I don't like it? That depends on what you think "the new namespace feature" is. If you don't want to use topic namespaces, then you don't have to. There's a default namespace that will not be shown (similar to default branch or empty topic). On the other hand, if you want to forever use "branch:topic" format that was never intended to be usable (e.g. hg up "branch:topic" doesn't necessarily do what you expect), then you can use old versions of evolve and topic. What version of evolve do you have? I think it is 10.1. It has been quite some time I installed it, and I don't recall whether I did it by pip or compiled it myself. Eye balling the help, I can find a command to determine evolve's version It's `hg version -v` and no, 10.1.0 definitely didn't have any topic namespaces. The new "branch//namespace/topic" format at the moment is only used in current default branch of evolve, which is not yet released, but will be a part of the upcoming release candidate (i.e. rc of 11.0.0). Also 10.1.0 is nowhere near "the current evolve version", it's from 2+ years ago, topic namespaces were still only in the plans. But the old "branch:topic" format was used in certain places like `hg branches`, where it shouldn't be. This will likely change in the future, since the UI part of topic namespaces feature is still being worked on. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
> 03.02.2023 00:34, Uwe Brauer пишет: > By "this" do you mean "branch:topic" or "branch//topic"? I meant "branch//topic" So can I switch the new namespace feature of, if I don't like it? > What version of evolve do you have? I think it is 10.1. It has been quite some time I installed it, and I don't recall whether I did it by pip or compiled it myself. Eye balling the help, I can find a command to determine evolve's version > At the moment we're planning to still support Mercurial 4.8. Good. > It would, but you should upgrade. I wish I could, but artemis (and issue tracker only runs up to my current hg version, the package is orphaned. Dan Villiom Podlaski Christiansen tried to port artemis to python 3.X but it turns out some functionality does not work, especially the numbering of the issues does not work -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ smime.p7s Description: S/MIME cryptographic signature ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
03.02.2023 00:34, Uwe Brauer пишет: 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) 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 I use topics quite extensively, but my collaborators not. Strangely enough I see this structure sometimes in the current evolve version (and it annoys me quite a bit). Will this behavior be configurable (ie. Switch it off)? By "this" do you mean "branch:topic" or "branch//topic"? What version of evolve do you have? BTW what are the minimum requirements for this evolve version you describe. At the moment we're planning to still support Mercurial 4.8. Would be hg 5.2 ok (either compiled with python 3.5 or 2.7)? It would, but you should upgrade. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
>>> "AS" == Anton Shestakov writes: Hi Anton, > 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 Strangely enough I see this sometimes in the current evolve version (and it annoys me quite a bit). Will this behavior be configurable (ie. Switch it off)? BTW what are the minimum requirements for this evolve version you describe. Would be hg 5.2 ok (either compiled with python 3.5 or 2.7)? Regards Uwe Brauer smime.p7s Description: S/MIME cryptographic signature ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Testing an RC of evolve 11.0.0 and topic 1.0.0
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. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
