Mercurial has a feature called "phases." When you push to a "publishing" repository, Mercurial sets the "phase" of the commit to "public" and Mercurial will refuse to let you modify/rewrite that commit. The purpose of this feature is to prevent you from footgunning yourself by rewriting history that has been shared with others. This is essentially formalization of the best practice that "thou shall not rewrite history and force push." Read more at https://hg.mozilla.org/mozilla-central/help/phases.
When phases is deployed properly, the feature helps prevents pain and suffering. Unfortunately, phases was not deployed properly on hg.mozilla.org. Mercurial repositories are publishing by default. You need to explicitly set a config option to make them non-publishing. We never set this config option on hg.mozilla.org, so all repositories were publishing. If you e.g. create a user repository, push a bookmark, then attempt to rewrite pushed changesets, your Mercurial client won't let you unless you manually reset the phase data locally. This is extremely annoying and makes modern (I dare say Git-like) workflows pretty much not possible when pushing to hg.mozilla.org. In other words, server badness made client-side development suffer as well. As of today, the configuration of phases on hg.mozilla.org has been fixed and *user repositories are now non-publishing by default*. If you push "draft" changesets to a user repository on hg.mozilla.org, they will remain as draft changesets and your Mercurial client will let you happily partake in modern workflows based on rewriting history. *All existing user repositories tied to active user accounts have been marked as non-publishing.* If for some reason you want to mark your user repository as publishing, `ssh hg.mozilla.org edit repo-name` will bring up a wizard that has an option to make repositories publishing. Also, there was previously an issue with replication from ssh:// hg.mozilla.org to https://hg.mozilla.org that was preventing bookmarks and phases from replicating properly. This issue has been resolved as of last Friday. You should now be able to use hg.mozilla.org as a sane repository hosting service. And since I know a few of you will ask, yes, it might be possible to enable obsolescence / changeset evolution on user repositories as an opt-in feature. I'm actively looking into this. If you would like the phases in your repository reset to draft, ping me on IRC and I'll happily do it as a one-off. If enough people ask, we'll make it self-service. If you notice any problems, head over to #vcs or bug 1089385. gps _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
