Size: 2801
Comment:
|
Size: 4132
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 26: | Line 26: |
* Prevent accidental rewritting part of the history expected to be immutable. | * Prevent accidental rewriting part of the history expected to be immutable. |
Line 69: | Line 69: |
Phase movement are automatic and transparent and most user don't have to care much about them. The base rule is very simple: “''Any changesets on a remote repository is seen a public''” One standard exchange commands, the phase of changesets on both side are compared. If differ the lowest phase is choosed. (eg: a changeset known as ''draft'' locally but '''public''' remotely is set public localy. Because public < draft) This update happen during standard exchange commands: * '''pull''': remote phase data are used to update the phase data on the local repo. * '''push''': remote phase data are used to the phase data on the local repo and then local phase data are pushed to the local repo. The real behavior is a it's a bit more complicated than '' changesets on a remote repository is seen a public'', but this is true for repository keeping default . If you need a finer behavior, consult the ''[[#Publishing_Repository|publishing repository]]'' section. New changeset committed locally are ''draft'', but some extension like ''mq'' may create ''secret'' and handle the move from ''secret'' to ''draft'' automatically Consult the [[#upgrade_Notes||upgrade Notes]] section to check how phase will move the first time a new version of Mercurial touch and existing repository. |
Phases
Contents
1. Introduction
The phase concept improves safety of history rewriting and control over changesets exchanged (read more). This phase concept aims to "just works" in a transparent manner for any user (read more). It is part of Core and always enabled in any new client but doesn't prevent older client to work on a repository (read more). Advanced user may decides to handle phase manually (read more).
Like bookmarks, phases are not stored in history and thus are not permanent and leave no audit trail.
This concept is introduced in Mercurial 2.1.
2. Available Phases
The phase concept allow to:
- Prevent accidental rewriting part of the history expected to be immutable.
- Keep immature changeset to be exchanged by mistake.
To achieve this, are three phases sharing a hierarchy of traits:
|
immutable |
shared |
public |
x |
x |
draft |
|
x |
secret |
|
|
* The public phases holds changeset announced publicly in. They are expect to
always exists in your history and are said immutable. History rewriting extension will refuse to delete such immutable changeset. Every changeset your push or pull from a public server are set in this phase.
* The draft phase holds changesets that was not expect marked as part of
- the permanent history. You can safely rewrite them. New commit are draft by default.
* The secret phase holds changeset that you do not want to exchange with
- other repository. Secret changeset are hidden to remote peer and won't be included in push operation. Manual operation or Extension may turn changeset secret.
Phases split the history in coherent set of changeset. Every changeset in a phase have ancestor in a phase compatible with its phase. Compatible means an changeset ancestors have at least the same traits that the children changeset. eg: A shared changeset alway have shared ancestor and an immutable changeset always have immutable ancestors.
In other word the phase of a changeset is alway equal of higher that the phase of it's descendant. According to the following order:
public < draft < secret
A changeset is not expected to automatically move from a lower phase to an higher phase (eg: from public to draft) but automatic
Phase movement are automatic and transparent and most user don't have to care much about them. The base rule is very simple: “ One standard exchange commands, the phase of changesets on both side are compared. If differ the lowest phase is choosed. (eg: a changeset known as This update happen during standard exchange commands: * pull: remote phase data are used to update the phase data on * push: remote phase data are used to the phase data on the local repo and The real behavior is a it's a bit more complicated than New changeset committed locally are Consult the #upgrade_Notes section to check how phase will move the first time a new version of Mercurial touch and existing repository.
(If you were looking to the developer oriented page: PhaseDevel) 3. Phase Movements
Any changesets on a remote repository is seen a public” 4. command line interface
4.1. core command
4.2. impact on extension
5. Publishing Repository
6. Upgrade Notes