|
Size: 2753
Comment: add a link to user page for changeset evolution.
|
Size: 1120
Comment: adding V1 format information
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| For a user perspective have a look at the ChangesetEvolution page | For a user perspective have a look at the ChangesetEvolution page. |
| Line 7: | Line 7: |
| Changesets evolution allows for safe rewriting of Mercurial history. This has a close relationship with Phases | == Obsstore Format == |
| Line 9: | Line 9: |
| Presentation of the concept: http://hg-lab.logilab.org/doc/mutable-history/html/ | |
| Line 11: | Line 10: |
| Related experimental extension (usable): http://bitbucket.org/marmoute/mutable-history/overview | Markers are stored in an append-only file stored in '.hg/store/obsstore'. |
| Line 13: | Line 13: |
| == Core principle == | == V1 (current) Format == |
| Line 15: | Line 15: |
| * 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 |
(see in line document for latest data) |
| Line 19: | Line 17: |
| == Additional ideas == | The file starts with a version header: |
| Line 21: | Line 19: |
| * 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) |
- 1 unsigned byte: version number, starting at zero. |
| Line 25: | Line 21: |
| == Handled situations == | |
| Line 27: | Line 22: |
| * 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) |
The header is followed by the markers. Each marker is made of: |
| Line 35: | Line 24: |
| == Changeset Obsolescence == | - 1 unsigned byte: number of new changesets "N", can be zero. |
| Line 37: | Line 26: |
| Obsolescence markers make it possible to mark changesets that have been deleted or superseded in a new version of the changeset. | - 1 unsigned 32-bits integer: metadata size "M" in bytes. |
| Line 39: | Line 28: |
| 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). | - 1 byte: a bit field. It is reserved for flags used in common obsolete marker operations, to avoid repeated decoding of metadata entries. |
| Line 41: | Line 32: |
| 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. | - 20 bytes: obsoleted changeset identifier. |
| Line 43: | Line 34: |
| 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. | - N*20 bytes: new changesets identifiers. - M bytes: metadata as a sequence of nul-terminated strings. Each string contains a key and a value, separated by a colon ':', without additional encoding. Keys cannot contain '\0' or ':' and values cannot contain '\0'. |
Implementation Details about Changesets Evolution
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
This page is intended for developer
For a user perspective have a look at the ChangesetEvolution page.
1. Obsstore Format
Markers are stored in an append-only file stored in '.hg/store/obsstore'.
2. V1 (current) Format
(see in line document for latest data)
The file starts with a version header:
- - 1 unsigned byte: version number, starting at zero.
The header is followed by the markers. Each marker is made of:
- - 1 unsigned byte: number of new changesets "N", can be zero. - 1 unsigned 32-bits integer: metadata size "M" in bytes. - 1 byte: a bit field. It is reserved for flags used in common
- obsolete marker operations, to avoid repeated decoding of metadata entries.
- string contains a key and a value, separated by a colon ':', without additional encoding. Keys cannot contain '\0' or ':' and values cannot contain '\0'.