Every time you perform history editing with the evolve extension enabled, your local Mercurial client is recording markers that say how commits were rewritten. Think of it as history of history. Because evolution is still an experimental feature, you must manually enable support on the server. Once you enable support, Mercurial clients with evolution enabled will automatically push and pull markers. And, any changesets on the server that are obsoleted via these markers will be hidden from view on the HTML interface and won't be served to clients.
FWIW, I investigated this a bit the other day and I believe we can safely enable obsolescence for user repos that opt into it. The patches are awaiting review in bug 925383. Truth be told, unless you are collaborating with other people using evolution, the benefit of enabling obsolescence on user repos is probably marginal. The bigger wins come from enabling obsolescence on the main repos. For example, when your push to MozReview gets landed by Autoland, Autoland can write an obsolescence marker so the next time you pull mozilla-central, your client will automatically clean up your old pushed commits that have since been rebased and landed. No manual branch/bookmark management necessary: Mercurial automatically sees the old commits have "evolved" and it hides them from you. It's "next generation" version control and I can't wait to experiment with time-saving workflows which it will enable. On Thu, Feb 12, 2015 at 8:49 PM, <nmara...@mozilla.com> wrote: > On Wednesday, February 11, 2015 at 1:04:55 PM UTC-8, Andrew Halberstadt > wrote: > > Thank you very much! This gets around the last major pain point with > > using bookmarks. And yes, changeset evolution please :). > > > > On 10/02/15 06:37 PM, Gregory Szorc wrote: > > > 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 > > > > > Thanks for all your work on Mercurial gps! I've been using evolve for a > few months locally now but I do not understand what you mean by enabling it > on the server. Will that affect how I do hg pushes to user repos after > amending/folding/pruning/solving patches? > > Nikhil > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
