Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | reftable: explicitly store update_index per ref | Shawn Pearce | 2017-08-21 | 1 | -0/+5 |
| | | | | | | | | | | | | | | | | | Add an update_index to every reference in a reftable, storing the exact transaction that last modified the reference. This is necessary to fix some merge race conditions. Consider updates at T1, T3 are present in two reftables. Compacting these will create a table with range [T1,T3]. If T2 arrives during or after the compaction its impossible for readers to know how to merge the [T1,T3] table with the T2 table. With an explicit update_index per reference, MergedReftable is able to individually sort each reference, merging individual entries at T3 from [T1,T3] ahead of identically named entries appearing in T2. Change-Id: Ie4065d4176a5a0207dcab9696ae05d086e042140 | ||||
* | reftable: file format documentation | Shawn Pearce | 2017-08-17 | 1 | -0/+950 |
Some repositories contain a lot of references (e.g. android at 866k, rails at 31k). The reftable format provides: - Near constant time lookup for any single reference, even when the repository is cold and not in process or kernel cache. - Near constant time verification a SHA-1 is referred to by at least one reference (for allow-tip-sha1-in-want). - Efficient lookup of an entire namespace, such as `refs/tags/`. - Support atomic push `O(size_of_update)` operations. - Combine reflog storage with ref storage. Change-Id: I29d0ff1eee475845660ac9173413e1407adcfbf2 |