|
Size: 1138
Comment: Very basic first draft about the evolution concept
|
Size: 5558
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| = Changeset Evolution Plan = /!\ This page is intended for developers |
|
| Line 5: | Line 3: |
| Proposition for safe rewriting of mercurial history. This will have a close relationship with StatesPlan | = Changesets Evolution Concept = |
| Line 7: | Line 5: |
| <<TableOfContents>> /!\ This feature is experimental and is only partially implemented in core Mercurial. Changesets evolution allows for safe rewriting of Mercurial history. This has a close relationship with [[Phases]] * Presentation of the concept: http://hg-lab.logilab.org/doc/mutable-history/html/ * Related experimental extension (usable): http://bitbucket.org/marmoute/mutable-history/overview |
|
| Line 10: | Line 17: |
| * Store and explicit relation between new and old version of rewritten changeset. | * Store an explicit obsolescence marker between new and old version of rewritten changeset. * This marker is *not* part of the changeset (should not alter the hash). * People are able to collaborate on evolving changeset |
| Line 12: | Line 21: |
| * This relation should *not* be part of the changeset (should not alter the hash). | == Additional ideas == |
| Line 14: | Line 23: |
| * People must be able to collaborate on evolving changeset | * Store final delta in a real and autonomous changeset. * The Obsolescence markers are exchangeable without rewritten changeset. * Easily allow other extension to manipulate such relation (and to hook on such operation) |
| Line 16: | Line 27: |
| == Handled situations == | |
| Line 17: | Line 29: |
| == Additional idea == | * Rewriting content of a changeset * Deleting/killing a changeset * Splitting a single changeset into multiple ones * Collapsing/folding multiple changeset into a single one * Changing changeset order * Adding (e.g., pulling) a changeset evolution that conflicts with another one * Adding (or adding in general) new changesets on one which already evolved (or evolving a changeset that have descendants) |
| Line 19: | Line 37: |
| * Save delta in a real changeset. | == Changeset Obsolescence == |
| Line 21: | Line 39: |
| * This relation should be exchangeable without rewritten changeset. | Obsolescence markers make it possible to mark changesets that have been deleted or superseded in a new version of the changeset. |
| Line 23: | Line 42: |
| * Easily allow other extension to manipulate such relation (and to hook on such operation) | Unlike the previous way of handling such changes, by stripping the old changesets from the repository, obsolescence markers can be propagated between repositories. This allows for a safe and simple way of exchanging mutable history and altering it after the fact. Changeset phases are respected, such that only draft and secret changesets can be altered (see `hg phases` for details). |
| Line 25: | Line 49: |
| == Situation that should be handled == | Obsolescence is tracked using "obsolescence markers", a piece of metadata that tracks which changesets have been made obsolete, potential successors for a given changeset, the moment the changeset was marked as obsolete, and the user who performed the rewriting operation. The markers are stored separately from standard changeset data can be exchanged without any of the precursor changesets, preventing unnecessary exchange of obsolescence data. |
| Line 27: | Line 56: |
| * Rewriting content of a changeset, | The complete set of obsolescence markers describes a history of changeset modifications that is orthogonal to the repository history of file modifications. This changeset history allows for detection and automatic resolution of edge cases arising from multiple users rewriting the same part of history concurrently. |
| Line 29: | Line 62: |
| * delete/kill a changeset. | == Current feature status == |
| Line 31: | Line 64: |
| * split a single changeset in multiple one, | This feature is still at development stage. While most part of Mercurial are now aware of the concept, some works remains to be done on user interface and network aspect. |
| Line 33: | Line 66: |
| * collapse multiple changeset in single one, | We do not recommend using this feature with version 2.5 of Mercurial unless you are an experienced user aware of the limitation of the current implementation. |
| Line 35: | Line 68: |
| * change changeset order, | == State of the concept in version 2.5 == |
| Line 37: | Line 70: |
| * adding (eg pulling) a changeset evolution that conflict with another one. | Commit --amend, rebase and histedit can now create obsolescence markers instead of stripping. This behavior is disabled by default. You need to explicitly enable obsolescence support to get this behavior. |
| Line 39: | Line 72: |
| * adding (or adding in general ) new changesets on a one which already evolved (or evolving a changeset that have descendant) | Some part of Mercurial comply with obsolescence marker, enforcing behavior as outlined below: Changesets marked as obsolete are: * hidden to all command unless the specify --hidden * excluded from push, pull, clone * selected by the 'obsolete()' revset In some situation you may have non-obsolete changesets descending from obsolete changesets. Such changesets are said to be "unstable": * push will refuse to push them without --force, * the 'unstable()' revset will select them, * their obsolete ancestors are displayed by log. In some other situation you may have successors for changesets which are now [[immutable||Phases]]. In such case the obsolescence marker does not apply and the unlucky successors are said to be "bumped": * push will refuse to push them without --force, * the 'bumped()' revset will select them, Finally when multiple changeset claim to be the successors of changesets they are said "divergent": * push will refuse to push them without --force, * the 'divergent()' revset will select them, * Changeset split have not detected as divergent. Obsolete changesets with no non-obsolete descendants are said to be "extinct" and will appear when querying the "extinct()" revset. Obsolescence markers will be exchanged between repositories that explicitly assert support for the obsolescence feature (this can currently only be done via an extension). log --graph will display use 'x' instead of 'o' to display obsolete changesets. Successors of a changeset are seen as valid destinations for bookmarks. == Experimental use == /!\ This feature is experimental! Do not try it unless you are an experienced Mercurial user. A set of extensions experimenting around the obsolescence concept is provided by Logilab. It has prototype implementation for most of the final feature. See its documentation for details: http://hg-lab.logilab.org/doc/mutable-history/html/ == Older materials == * Initial presentation at Copenhagen: http://public.octopoid.net/talk.pdf * First tutorial, written by Peter Arrenbrecht: http://arrenbrecht.ch/mercurial/evolution/ |
Changesets Evolution Concept
Contents
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
This feature is experimental and is only partially implemented in core Mercurial.
Changesets evolution allows for safe rewriting of Mercurial history. This has a close relationship with Phases
Presentation of the concept: http://hg-lab.logilab.org/doc/mutable-history/html/
Related experimental extension (usable): http://bitbucket.org/marmoute/mutable-history/overview
1. Core principle
- Store an explicit obsolescence marker between new and old version of rewritten changeset.
- This marker is *not* part of the changeset (should not alter the hash).
- People are able to collaborate on evolving changeset
2. Additional ideas
- Store final delta in a real and autonomous changeset.
- The Obsolescence markers are exchangeable without rewritten changeset.
- Easily allow other extension to manipulate such relation (and to hook on such operation)
3. Handled situations
- Rewriting content of a changeset
- Deleting/killing a changeset
- Splitting a single changeset into multiple ones
- Collapsing/folding multiple changeset into a single one
- Changing changeset order
- Adding (e.g., pulling) a changeset evolution that conflicts with another one
- Adding (or adding in general) new changesets on one which already evolved (or evolving a changeset that have descendants)
4. Changeset Obsolescence
Obsolescence markers make it possible to mark changesets that have been deleted or superseded in a new version of the changeset.
Unlike the previous way of handling such changes, by stripping the old changesets from the repository, obsolescence markers can be propagated between repositories. This allows for a safe and simple way of exchanging mutable history and altering it after the fact. Changeset phases are respected, such that only draft and secret changesets can be altered (see hg phases for details).
Obsolescence is tracked using "obsolescence markers", a piece of metadata that tracks which changesets have been made obsolete, potential successors for a given changeset, the moment the changeset was marked as obsolete, and the user who performed the rewriting operation. The markers are stored separately from standard changeset data can be exchanged without any of the precursor changesets, preventing unnecessary exchange of obsolescence data.
The complete set of obsolescence markers describes a history of changeset modifications that is orthogonal to the repository history of file modifications. This changeset history allows for detection and automatic resolution of edge cases arising from multiple users rewriting the same part of history concurrently.
5. Current feature status
This feature is still at development stage. While most part of Mercurial are now aware of the concept, some works remains to be done on user interface and network aspect.
We do not recommend using this feature with version 2.5 of Mercurial unless you are an experienced user aware of the limitation of the current implementation.
6. State of the concept in version 2.5
Commit --amend, rebase and histedit can now create obsolescence markers instead of stripping. This behavior is disabled by default. You need to explicitly enable obsolescence support to get this behavior.
Some part of Mercurial comply with obsolescence marker, enforcing behavior as outlined below:
Changesets marked as obsolete are:
- hidden to all command unless the specify --hidden
- excluded from push, pull, clone
- selected by the 'obsolete()' revset
In some situation you may have non-obsolete changesets descending from obsolete changesets. Such changesets are said to be "unstable":
- push will refuse to push them without --force,
- the 'unstable()' revset will select them,
- their obsolete ancestors are displayed by log.
In some other situation you may have successors for changesets which are now immutable. In such case the obsolescence marker does not apply and the unlucky successors are said to be "bumped":
- push will refuse to push them without --force,
- the 'bumped()' revset will select them,
Finally when multiple changeset claim to be the successors of changesets they are said "divergent":
- push will refuse to push them without --force,
- the 'divergent()' revset will select them,
- Changeset split have not detected as divergent.
Obsolete changesets with no non-obsolete descendants are said to be "extinct" and will appear when querying the "extinct()" revset.
Obsolescence markers will be exchanged between repositories that explicitly assert support for the obsolescence feature (this can currently only be done via an extension).
log --graph will display use 'x' instead of 'o' to display obsolete changesets.
Successors of a changeset are seen as valid destinations for bookmarks.
7. Experimental use
This feature is experimental! Do not try it unless you are an experienced Mercurial user.
A set of extensions experimenting around the obsolescence concept is provided by Logilab. It has prototype implementation for most of the final feature. See its documentation for details:
http://hg-lab.logilab.org/doc/mutable-history/html/
8. Older materials
Initial presentation at Copenhagen: http://public.octopoid.net/talk.pdf
First tutorial, written by Peter Arrenbrecht: http://arrenbrecht.ch/mercurial/evolution/