Enable exchange of obsolete (evolve) markers for Mercurial (BB-7852)

Issue #6710 resolved
Sean Farley
created an issue

Obsolete markers have been in core for a few versions now but with Mercurial 2.5, exchanging them on a server requires only two lines in the .hgrc, similar to issue #4560. Without exchanging these markers, this is a huge road block for using the changeset evolution workflow.

Official response

Comments (50)

  1. MattT

    Even without any changes to the Bitbucket UI, having obsolete markers exchanged would be very helpful. This would enable the results rebasing, pruning, amending and so on on the command line using the hg client to be represented in the state on the server.

  2. Ulrik Johansson

    Mercurial 3.0 is soon here, and with it Changeset Evolution has now moved into core if I'm not mistaken. This issue has not had an official update for a good while now. Has this issue moved up the priority queue now or will it stay on hold?

  3. Gregory Szorc

    Changeset evolution is not in the core yet. Preliminary support for exchanging obsolescence markers is in core (and has been for a while). But it needs improvements to work at scale. These improvements are kinda/sorta implemented in the mutable-history extension. Features will make their way to core over time.

  4. Martin Geisler

    There were 12 votes as of 2013-12-15 and we now have 52 votes. That's enough to get to the middle of the second page when you list all issues and sort by votes.

    I suggest telling friends and colleagues about this issue and get them to vote for it!

  5. Faheem Mitha

    Martin, I concur with your comment above. I think it would make sense to post this to the mercurial mailing lists, unless you have already. We should be able to get more votes; mercurial has more than 50-odd users.

  6. Sébastien GAUTRIN

    Any updates on this?

    I don't have a specific timeline for this yet, but it's something we plan on addressing when we upgrade from Mercurial 2.2 to the latest release.

    Bitbucket is using 2.9 now, and as stated by the OP, this should be a really simple thing to add, in the same way support for phase had been added in #4560

    Being able to actually use evolve markers with Bitbucket would actually be a great help to the betterment of mercurial, as it'd be much easier to test the upcoming evolve feature in real condition and help iron out the quirks before it gets into core.

  7. Aurélien Campéas

    Hi, I'm told people can get the magic "enable exchange of obsolete markers" if they ask you on #irc. I don't want to irc ... but can you activate this for the people in this thread ? Thanks in advance.

  8. Sébastien GAUTRIN

    Any movement on that front? Can we expect being able to access the feature at least in beta any time soon (considering there seem to have been a private beta 9 months ago for a select few users on #irc)?

  9. Aurélien Campéas

    From the discussions that happened in the October Paris Mercurial Sprint (held @Mozilla), I understood that bitbucket only wants to deploy something for which they can provide clear usage guidelines, that has no major performance issues, in short: production-ready. The "topic branches" features might be the missing link (with a few other corner case issues). I'm even willing to fund (part of) developments on this front, but have yet to find a qualified volunteer to do the job ... Pierre-Yves, are you listening ? ;)

  10. Sébastien GAUTRIN

    Recent blog about squashing commit gives us some update about the issue; not much but still better than this ticket. Squash commits when merging a Git branch with Bitbucket

    In particular, there's a section about squash merging with Mercurial which mentions evolve support:

    This feature rollout applies only to Git and not Mercurial… yet. Squash requires exchange of obsolescence markers – part of the evolve extension – so we’re working with Mercurial’s maintainers to get evolve bundled in core Mercurial, as well as adding support for it in Bitbucket. For developers already using the evolve extension, we hope to have a beta for squashing in Mercurial available soon.

    Now, with the team hoping to have a beta for squashing in Mercurial available soon™, this means that they also hope to have at least a beta of evolve support soon™er. Though the quote also says they seem to be waiting for evolve to be bundled with Mercurial, which might not be so soon; it's a shame because having minimal evolve support in Bitbucket would most likely greatly help evolve development with having more people able to properly test it in a distributed setup and not just locally.

    However, with release of evolve 5.6.0, main developer announced that the plan now is (among other things) to refactor the extension to use the hgext3rd mechanism, so having the extension bundled in mercurial is maybe not too far away now.

    @Aurélien Campéas: are the "topic branches" features the experimentations in progress in https://www.mercurial-scm.org/repo/topic-experiment?

  11. Sean Farley reporter

    And on the eve of the four-year anniversary of my own report, I mark this issue as resolved. Everyone, check your Account / Settings / Integrations and Features / Labs page!

  12. Max Grender-Jones

    Awesome! A few questions:

    • Does the UI behave nicely?
    • What risk is there that this will be taken away again (it's a total nightmare to try to get rid of evolve-tagged changesets if you want to turn off evolve-again)
    • We mirror our repository to git using the hg-git extension. Anyone know if git mirroring and evolve play nicely together?
    • Does this mean we might get squash-merge as an option some time soon?
  13. Sean Farley reporter

    Hi @Max Grender-Jones,

    Does the UI behave nicely?

    It should, yes. I've implemented basic support for pull requests and the commit page. Here is an example of an obsolete commit, with a successor commit:


    The pull request code needs another pass but let me know if it doesn't work for you (also, expect it to only work with named branches for now).

    What risk is there that this will be taken away again (it's a total nightmare to try to get rid of evolve-tagged changesets if you want to turn off evolve-again)

    That's more of a Mercurial question since the obsstore is, by design, append-only. If you turn off the labs feature, then that will disable exchange of the obsolete markers. That's it. Core Mercurial has known how to ignore those changesets since version 2.5, though.

    We mirror our repository to git using the hg-git extension. Anyone know if git mirroring and evolve play nicely together?

    That's a difficult question. Evolution (and putting the branch name into the commit metada, aka only one branch per commit) is quite a different (philosophical) design than git. I have some patches that improve the integration but they are only quasi-finished (I use them daily, for what it's worth).

    Does this mean we might get squash-merge as an option some time soon?

    Yep :-)

  14. Andy Lee

    I'm actually new to using Bitbucket+hg but I figured I'd live dangerously and try out the new evolution support on a pull request I'm working on. After making changes based on reviewer feedback I updated the original changeset via 'hg commit --amend' and pushed up to my fork. The pull request automatically updated as I would have expected and the previous version of the commit was properly marked as obsolete; nice! Awesome to see evo getting support like this!

    Only feedback I have to offer is that it'd be nice to have an easier way to view/compare the previous versions (the obsolete ones) of the changeset in the pull request view, but at least you can access them from the 'Activity' tab right now.

  15. Log in to comment