|
Size: 1313
Comment:
|
Size: 2801
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 14: | Line 14: |
| prevent older client to work on a repository ([[#Upgrade_Notes|read more]]). Advanced user may decide handle phase manually ([[#Publishing Repository|read more]]). |
prevent older client to work on a repository ([[#Upgrade_Notes|read more]]). Advanced user may decides to handle phase manually ([[#Publishing Repository|read more]]). Like bookmarks, phases are not stored in history and thus are not permanent and leave no audit trail. |
| Line 24: | Line 27: |
| Line 27: | Line 29: |
| To achieve this, your history is splitted in three ''phases'''. These phases share a hierarchy of traits: |
To achieve this, are three phases sharing a hierarchy of traits: |
| Line 32: | Line 33: |
| ||draft || ||x || | ||draft || || x|| |
| Line 34: | Line 35: |
* '''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 |
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 rewritting 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
(If you were looking to the developer oriented page: PhaseDevel) 3. Phase Movements
4. command line interface
4.1. core command
4.2. impact on extension
5. Publishing Repository
6. Upgrade Notes