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.
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.
Yes, that's a very good point.
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.
@Brodie Rao Is there any updates on this? This could be a killer feature for Mercurial!
Any updates on this? It'd be great to have support before this goes into core.
Given that we now have non-publishing repositories (https://bitbucket.org/site/master/issue/4560/provide-a-method-for-setting-the-phase-of), it'd be great to see this one implemented too.
Removing component: repository (automated comment)
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?
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.
Gregory: Ok, sorry for spreading misinformation, and thanks for clarifying things.
It would be good to have this feature. An increasing number of people are now using evolve, which depends on this. I just reports a bug which depends on obsolescent markers being available,. See https://bitbucket.org/tortoisehg/hgtk/issue/1882/traceback-when-clicking-check-for-incoming
Need this for maintaining a parallel Python 3 port of SCons with rebases.
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!
Please. Thanks.
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.
People are learning how to use evolve, we have users with questions about it on #mercurial at freenode and on the user mailing list, and a new shiny user manual is available http://evolution.experimentalworks.net/doc/user-guide.html .
want it on bitbucket!
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.
This still breaks SCons workflow. See https://bitbucket.org/scons/scons/pull-request/224/bug-2831-allow-appending-help-text-to/diff#comment-5720236
Now that I work here, I've put this issue on my plate.
That's great news :)
This is really great.
Any idea how long it might take ?
There's no timeline, of course, but I am actively working on it now.
Hello @Sean Farley,
Any progress on the subject ?
Yes, I'm working on two large roadblocks this week.
Good, we are waiting for this to switch to bitbucket.
Hope it's not a long wait :)
:+1:
GO @Sean Farley GO !!!!!!
I was in London for the Mercurial Sprint. Haven't dropped this work, though. Just keeping the users updated.
Hi @Sean Farley, may be have sense to change the issue status to open?
Fair enough. I'm actively working on this, so let's open it.
Can't wait to have Evolve on Bitbucket !
Hey @Sean Farley, any progress on this issue? Anything blocking it?
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.
Hi @Sean Farley! Any chance to get a pre-access to the feature, or be a beta-tester? Thanks!
I would be interested as well, but moreover, getting some update on the progress would be nice: surely it has evolved (no pun intended) somehow in 9 months.
Still waiting for.
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)?
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 ? ;)
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?
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!
OMG! Unbelievable :)
Awesome! A few questions:
hg-git extension. Anyone know if git mirroring and evolve play nicely together?
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:
https://bitbucket.org/seanfarley/mercurial/commits/43c5526916752b0f7476a26069709f35590ddb04
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 :-)
Hi Max,
I use hg-git daily with evolve: no issue for me.
@Sébastien GAUTRIN yes this is the "topic branches" repo.
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.
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!