Re: [PATCH v2 12/15] Documentation/technical: describe multi-pack reverse indexes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
> index 77eb591057..4bbbb188a4 100644
> --- a/Documentation/technical/pack-format.txt
> +++ b/Documentation/technical/pack-format.txt
> @@ -387,12 +387,15 @@ be used to generate a reverse index.
> 
>  Instead of mapping between offset, pack-, and index position, this
>  reverse index maps between an object's position within the MIDX, and
> -that object's position within a pseudo-pack that the MIDX describes.
> +that object's position within a pseudo-pack that the MIDX describes
> +(i.e., the ith entry of the multi-pack reverse index holds the MIDX
> +position of ith object in pseudo-pack order).
> 
> -To clarify these three orderings, consider a multi-pack reachability
> -bitmap (which does not yet exist, but is what we are building towards
> -here). Each bit needs to correspond to an object in the MIDX, and so we
> -need an efficient mapping from bit position to MIDX position.
> +To clarify the difference between these orderings, consider a multi-pack
> +reachability bitmap (which does not yet exist, but is what we are
> +building towards here). Each bit needs to correspond to an object in the
> +MIDX, and so we need an efficient mapping from bit position to MIDX
> +position.
> 
>  One solution is to let bits occupy the same position in the oid-sorted
>  index stored by the MIDX. But because oids are effectively random, there

Thanks - this diff makes sense.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux