|
Size: 1120
Comment: adding V1 format information
|
Size: 1683
Comment: adds motivation for the new format
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| == V1 (current) Format == | === V1 (current) Format === |
| Line 19: | Line 19: |
| - 1 unsigned byte: version number, starting at zero. | * 1 unsigned byte: version number, starting at zero. |
| Line 24: | Line 24: |
| - 1 unsigned byte: number of new changesets "N", can be zero. | * 1 unsigned byte: number of new changesets "N", can be zero. |
| Line 26: | Line 26: |
| - 1 unsigned 32-bits integer: metadata size "M" in bytes. | * 1 unsigned 32-bits integer: metadata size "M" in bytes. |
| Line 28: | Line 28: |
| - 1 byte: a bit field. It is reserved for flags used in common | * 1 byte: a bit field. It is reserved for flags used in common |
| Line 32: | Line 32: |
| - 20 bytes: obsoleted changeset identifier. | * 20 bytes: obsoleted changeset identifier. |
| Line 34: | Line 34: |
| - N*20 bytes: new changesets identifiers. | * N*20 bytes: new changesets identifiers. |
| Line 36: | Line 36: |
| - M bytes: metadata as a sequence of nul-terminated strings. Each | * M bytes: metadata as a sequence of nul-terminated strings. Each |
| Line 40: | Line 40: |
=== V2 (current) Format === There is two extra information we would like to see in a second version of the format: * date: There is currently *always* a date in the meta data. So storing it explicitly would be more space efficient. It would also open the way to quickly access the date for sorting purpose (no use case yet but not crazy to think about it) * parents: When a changesets is pruned (obsoleted, no successors) we needs to records its parents. This is necessary to link the markers chain to the push/pull operation it is relevant to. |
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'.
1.1. 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.
- 20 bytes: obsoleted changeset identifier.
- 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'.
1.2. V2 (current) Format
There is two extra information we would like to see in a second version of the format:
- date: There is currently *always* a date in the meta data. So storing it explicitly would be more space efficient. It would also open the way to quickly access the date for sorting purpose (no use case yet but not crazy to think about it)
- parents: When a changesets is pruned (obsoleted, no successors) we needs to records its parents. This is necessary to link the markers chain to the push/pull operation it is relevant to.