|
Size: 1517
Comment:
|
Size: 3218
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| <<Include(A:dev)>> <<Include(A:style)>> |
|
| Line 5: | Line 3: |
| = Changeset Evolution Plan = | = ChangesetsObsolescence = |
| Line 7: | Line 5: |
| Proposition for safe rewriting of mercurial history. This will have a close relationship with StatesPlan | <<TableOfContents>> |
| Line 9: | Line 7: |
| * Presentation of the concept: http://hg-lab.logilab.org/doc/mutable-history/html/ * Related experimental extension (usable): http://bitbucket.org/marmoute/mutable-history/overview |
/!\ this feature is experimental and only partially implement in core |
| Line 12: | Line 9: |
| Older materials | == Overview == |
| Line 14: | Line 11: |
| * Initial presentation at Copenhagen: http://public.octopoid.net/talk.pdf * First tutorial written by Parren: http://arrenbrecht.ch/mercurial/evolution/ |
Obsolescence markers make it possible to mark changesets that have been deleted or superset 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:`hg phases` for details). Obsolescence is tracked using "obsolete markers", a piece of metadata tracking 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. == Current feature status == This feature is still at an early stage of development. While several core behaviors have been adjusted to take obsolescence markers into account, some parts of Mercurial are still unaware of the new concept. We do not recommend using this feature with version 2.3 of Mercurial. |
| Line 18: | Line 43: |
| == Core principle == | == Available in version 2.3 == |
| Line 20: | Line 45: |
| * Store and explicit relation between new and old version of rewritten changeset. * This relation should *not* be part of the changeset (should not alter the hash). * People must be able to collaborate on evolving changeset |
There is currently no functionality in core Mercurial to create obsolescence markers. Markers can be created using third-party extensions, and some parts of Mercurial will comply with the markers, enforcing behavior as outlined below: |
| Line 24: | Line 50: |
| Changesets marked as obsolete are: | |
| Line 25: | Line 52: |
| == Additional idea == | * hidden from log, * excluded from push, pull, clone, * selected by the 'obsolete()' revset. |
| Line 27: | Line 56: |
| * Save delta in a real changeset. * This relation should be exchangeable without rewritten changeset. * Easily allow other extension to manipulate such relation (and to hook on such operation) |
In some situation you may have non-obsolete changesets descending from obsolete changesets. Such changesets are said to be "unstable": |
| Line 31: | Line 59: |
| == Situation that should be handled == | * push will refuse to push them without --force, * the 'unstable()' revset will select them, * their obsolete ancestors are displayed by log. |
| Line 33: | Line 63: |
| * Rewriting content of a changeset, * delete/kill a changeset. * split a single changeset in multiple one, * collapse multiple changeset in single one, * change changeset order, * adding (eg pulling) a changeset evolution that conflict with another one. * adding (or adding in general ) new changesets on a one which already evolved (or evolving a changeset that have descendant) |
Obsolete changesets with no non-obsolete descendants are said to be "extinct" and will appear when querying the "extinct()" revset. |
| Line 41: | Line 66: |
| CategoryProject | 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. == Experimental user == /!\ this feature is experimental do not try it unless you are an experimented user of Mercurial A set of extension experimenting around the obsolescence concept is provided by Logilab. See its documentation for details: http://hg-lab.logilab.org/doc/mutable-history/html/ |
ChangesetsObsolescence
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
this feature is experimental and only partially implement in core
1. Overview
Obsolescence markers make it possible to mark changesets that have been deleted or superset 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:hg phases for details).
Obsolescence is tracked using "obsolete markers", a piece of metadata tracking 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.
2. Current feature status
This feature is still at an early stage of development. While several core behaviors have been adjusted to take obsolescence markers into account, some parts of Mercurial are still unaware of the new concept.
We do not recommend using this feature with version 2.3 of Mercurial.
3. Available in version 2.3
There is currently no functionality in core Mercurial to create obsolescence markers. Markers can be created using third-party extensions, and some parts of Mercurial will comply with the markers, enforcing behavior as outlined below:
Changesets marked as obsolete are:
- hidden from log,
- 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.
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.
4. Experimental user
this feature is experimental do not try it unless you are an experimented user of Mercurial
A set of extension experimenting around the obsolescence concept is provided by Logilab. See its documentation for details: