Differences between revisions 8 and 9
Revision 8 as of 2008-04-07 22:26:20
Size: 1686
Editor: abuehl
Comment: changed cat
Revision 9 as of 2009-05-19 19:31:00
Size: 1691
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
RevlogNG was introduced with Mercurial 0.9 (see also ["Revlog"]). RevlogNG was introduced with Mercurial 0.9 (see also [[Revlog]]).
Line 41: Line 41:
For how renames are stored see "[http://selenic.com/pipermail/mercurial/2008-February/017139.html Problems extracting renames]", a reply by [:mpm] posted on Feb 12, 2008, on the [http://selenic.com/pipermail/mercurial/ mercurial mailing list]. For how renames are stored see "[[http://selenic.com/pipermail/mercurial/2008-February/017139.html|Problems extracting renames]]", a reply by [[mpm]] posted on Feb 12, 2008, on the [[http://selenic.com/pipermail/mercurial/|mercurial mailing list]].

RevlogNG was introduced with Mercurial 0.9 (see also Revlog).

Deficiencies in original revlog format:

  • no uncompressed revision size stored
  • SHA1 hash is potentially too weak
  • compression context for deltas is often too small
  • offset range is limited to 4MB
  • some metadata is indicated by escaping in the data

The original index format was:

  • 4 bytes: offset
  • 4 bytes: compressed length
  • 4 bytes: base revision
  • 4 bytes: link revision
  • 20 bytes: nodeid
  • 20 bytes: parent 1 nodeid
  • 20 bytes: parent 2 nodeid
  • 72 bytes total

RevlogNG format:

  • 6 bytes: offset (allows for 256TB of compressed history per file)
  • 2 bytes: flags
  • 4 bytes: compressed length
  • 4 bytes: uncompressed length
  • 4 bytes: base revision
  • 4 bytes: link revision
  • 4 bytes: parent 1 revision
  • 4 bytes: parent 2 revision
  • 32 bytes: nodeid
  • 64 bytes total

RevlogNG header:

As the offset of the first data chunk is always zero, the first 4 bytes (part of the offset) are used to indicate revlog version number and flags. all values are in big endian format.

RevlogNG also supports interleaving of index and data. This can greatly reduce storage overhead for smaller revlogs. In this format, the data chunk immediately follows its index entry. The position of the next index entry is calculated by adding the compressed length to the offset.

For how renames are stored see "Problems extracting renames", a reply by mpm posted on Feb 12, 2008, on the mercurial mailing list.


CategoryInternals

RevlogNG (last edited 2020-01-13 04:19:53 by aayjaychan)