Vicent Marti <tan...@gmail.com> writes:
> This is the technical documentation and design rationale for the new
> Bitmap v2 on-disk format.
Hrmpf, that's what I get for reading the series in order...
> + The folowing flags are supported:
typos marked by ^
> + By storing all the hashes in a cache together with the bitmapsin
> + The obvious consequence is that the XOR of all 4 bitmaps will
> + in a full set (all bits sets), and the AND of all 4 bitmaps will
> + - 1-byte XOR-offset
> + The xor offset used to compress this bitmap. For an
> + in position `x`, a XOR offset of `y` means that the
> + bitmap representing for this commit is composed by
> XORing the
> + bitmap for this entry with the bitmap in entry `x-y`
> + the bitmap `y` entries before this one).
> + Note that this compression can be recursive. In order to
> + XOR this entry with a previous one, the previous entry
> + to be decompressed first, and so on.
> + The hard-limit for this offset is 160 (an entry can
> only be
> + xor'ed against one of the 160 entries preceding it).
> + number is always positivea, and hence entries are
> always xor'ed
> + with **previous** bitmaps, not bitmaps that will come
> + in the index.
Clever. Why 160 though?
> + - 2 bytes of RESERVED data (used right now for better packing).
What do they mean?
> + With an index at the end of the file, we can load only this index in
> + allowing for very efficient access to all the available bitmaps lazily (we
> + have their offsets in the mmaped file).
Is there anything preventing you from mmap()ing the index also?
> +== Appendix A: Serialization format for an EWAH bitmap
> +Ewah bitmaps are serialized in the protocol as the JAVAEWAH
> +library, making them backwards compatible with the JGit
> + - 4-byte number of bits of the resulting UNCOMPRESSED bitmap
> + - 4-byte number of words of the COMPRESSED bitmap, when stored
> + - N x 8-byte words, as specified by the previous field
> + This is the actual content of the compressed bitmap.
> + - 4-byte position of the current RLW for the compressed
> + bitmap
> +Note that the byte order for this serialization is not defined by
> +default. The byte order for all the content in a serialized EWAH
> +bitmap can be known by the byte order flags in the header of the
> +bitmap index file.
Please document the RLW format here.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html