This is the final part of a series of posts about the new phases feature we implemented for mercurial 2.1. The first part talks about how phases will help mercurial users, the second part explains how to control them. This one explains what people should take care of when upgrading.
Phases do not require any conversion of your repos. Phase information is not stored in changesets. Everybody using a new client will take advantage of phases on any repository they touch.
However there is some points you need to be aware of regarding interaction between the old world without phases and the new world with phases:
As ever, the Mercurial wire protocol (used to communicate through http and ssh) is fully backward compatible . But as old Mercurial versions are not aware of phases, old servers will always be treated as publishing.
A new client has no way to determine which parts of the history should be immutable and which parts should not. In order to fail safely, a new repo will mark everything as public when no data is available. For example, in the scenario described in part I, if an old version of mercurial were used to clone and commit, a new version of mercurial will see them as public and refuse to rebase them.
Some extensions (like mq) may provide smarter logic to set some changesets to the draft or even secret phases.
The phased client will write phase data to the old repo on its first write operation.
Everything works fine except that the old client is unable to see or manipulate phases:
So, if you actively rewrite your history or use secret changesets, you should ensure that only new clients touch those repositories where the phase matters.
Several situations can result in bad phases in a repository:
The easiest way to restore a consistant state is to use the phase command. In most cases, changesets marked as public but absent from your real public server should be moved to draft:
hg phase --force --draft 'public() and outgoing()'
If you have multiple public servers, you can pull from the others to retrieve their phase data too.
Mercurial's phases are a simple concept that adds always on and transparent safety for most users while not preventing advanced ones from doing whatever they want.
Behind this safety-enabling and useful feature, phases introduce in Mercurial code the concept of sharing mutable parts of history. The introduction of this feature paves the way for advanced history rewriting solutions while allowing safe and easy sharing of mutable parts of history. I'll post about those future features shortly.