Branch:
master
master
next
stable-0.10
stable-0.11
stable-0.12
stable-0.7
stable-0.8
stable-0.9
stable-1.0
stable-1.1
stable-1.2
stable-1.3
stable-2.0
stable-2.1
stable-2.2
stable-2.3
stable-3.0
stable-3.1
stable-3.2
stable-3.3
stable-3.4
stable-3.5
stable-3.6
stable-3.7
stable-4.0
stable-4.1
stable-4.10
stable-4.11
stable-4.2
stable-4.3
stable-4.4
stable-4.5
stable-4.6
stable-4.7
stable-4.8
stable-4.9
stable-5.0
stable-5.1
stable-5.2
stable-5.3
stable-5.4
stable-5.5
stable-5.6
stable-5.7
stable-5.8
spearce-gpg-pub
v0.10.1
v0.11.1
v0.11.3
v0.12.1
v0.7.0
v0.7.1
v0.8.1
v0.8.4
v0.9.1
v0.9.3
v1.0.0.201106011211-rc3
v1.0.0.201106051725-r
v1.0.0.201106071701-r
v1.0.0.201106081625-r
v1.0.0.201106090707-r
v1.1.0.201109011030-rc2
v1.1.0.201109071825-rc3
v1.1.0.201109151100-r
v1.2.0.201112221803-r
v1.3.0.201202121842-rc4
v1.3.0.201202151440-r
v2.0.0.201206130900-r
v2.1.0.201209190230-r
v2.2.0.201212191850-r
v2.3.0.201302130906
v2.3.1.201302201838-r
v3.0.0.201305080800-m7
v3.0.0.201305281830-rc2
v3.0.0.201306040240-rc3
v3.0.0.201306101825-r
v3.0.2.201309041250-rc2
v3.0.2.201311090911-r
v3.0.3.201309161630-r
v3.1.0.201309270735-rc1
v3.1.0.201310021548-r
v3.2.0.201311130903-m3
v3.2.0.201312181205-r
v3.3.0.201402191814-rc1
v3.3.0.201403021825-r
v3.3.1.201403241930-r
v3.3.2.201404171909-r
v3.4.0.201405051725-m7
v3.4.0.201405211411-rc1
v3.4.0.201405281120-rc2
v3.4.0.201406041058-rc3
v3.4.0.201406110918-r
v3.4.1.201406201815-r
v3.4.2.201412180340-r
v3.5.0.201409071800-rc1
v3.5.0.201409260305-r
v3.5.1.201410131835-r
v3.5.2.201411120430-r
v3.5.3.201412180710-r
v3.6.0.201411121045-m1
v3.6.0.201412230720-r
v3.6.1.201501031845-r
v3.6.2.201501210735-r
v3.7.0.201502031740-rc1
v3.7.0.201502260915-r
v3.7.1.201504261725-r
v4.0.0.201503231230-m1
v4.0.0.201505050340-m2
v4.0.0.201505191015-rc1
v4.0.0.201505260635-rc2
v4.0.0.201506020755-rc3
v4.0.0.201506090130-r
v4.0.1.201506240215-r
v4.1.0.201509280440-r
v4.1.1.201511131810-r
v4.1.2.201602141800-r
v4.10.0.201712302008-r
v4.11.0.201803080745-r
v4.11.1.201807311124-r
v4.11.2.201809100523-r
v4.11.3.201809181037-r
v4.11.4.201810060650-r
v4.11.5.201810191925-r
v4.11.6.201812241910-r
v4.11.7.201903122105-r
v4.11.8.201904181247-r
v4.11.9.201909030838-r
v4.2.0.201511101648-m1
v4.2.0.201601211800-r
v4.3.0.201603230630-rc1
v4.3.0.201604071810-r
v4.3.1.201605051710-r
v4.4.0.201605041135-m1
v4.4.0.201605250940-rc1
v4.4.0.201606011500-rc2
v4.4.0.201606070830-r
v4.4.1.201607150455-r
v4.5.0.201609210915-r
v4.5.1.201703201650-r
v4.5.2.201704071617-r
v4.5.3.201708160445-r
v4.5.4.201711221230-r
v4.5.5.201812240535-r
v4.5.6.201903121547-r
v4.5.7.201904151645-r
v4.6.0.201612231935-r
v4.6.1.201703071140-r
v4.7.0.201704051617-r
v4.7.1.201706071930-r
v4.7.2.201807261330-r
v4.7.3.201809090215-r
v4.7.4.201809180905-r
v4.7.5.201810051826-r
v4.7.6.201810191618-r
v4.7.7.201812240805-r
v4.7.8.201903121755-r
v4.7.9.201904161809-r
v4.8.0.201705170830-rc1
v4.8.0.201706111038-r
v4.9.0.201710071750-r
v4.9.1.201712030800-r
v4.9.10.201904181027-r
v4.9.2.201712150930-r
v4.9.3.201807311005-r
v4.9.4.201809090327-r
v4.9.5.201809180939-r
v4.9.6.201810051924-r
v4.9.7.201810191756-r
v4.9.8.201812241815-r
v4.9.9.201903122025-r
v5.0.0.201805151920-m7
v5.0.0.201805221745-rc1
v5.0.0.201805301535-rc2
v5.0.0.201806050710-rc3
v5.0.0.201806131550-r
v5.0.1.201806211838-r
v5.0.2.201807311906-r
v5.0.3.201809091024-r
v5.1.0.201808281540-m3
v5.1.0.201809051400-rc1
v5.1.0.201809111528-r
v5.1.1.201809181055-r
v5.1.10.201908230655-r
v5.1.11.201909031202-r
v5.1.12.201910011832-r
v5.1.13.202002110435-r
v5.1.2.201810061102-r
v5.1.3.201810200350-r
v5.1.4.201812251853-r
v5.1.5.201812261915-r
v5.1.6.201903130242-r
v5.1.7.201904200442-r
v5.1.8.201906050907-r
v5.1.9.201908210455-r
v5.2.0.201811281532-m3
v5.2.0.201812061821-r
v5.2.1.201812262042-r
v5.3.0.201901161700-m1
v5.3.0.201901162155-m1
v5.3.0.201903061415-rc1
v5.3.0.201903130848-r
v5.3.1.201904271842-r
v5.3.2.201906051522-r
v5.3.3.201908210735-r
v5.3.4.201908231101-r
v5.3.5.201909031855-r
v5.3.6.201910020505-r
v5.3.7.202002110540-r
v5.4.0.201905081430-m2
v5.4.0.201905221418-m3
v5.4.0.201906121030-r
v5.4.1.201908211225-r
v5.4.2.201908231537-r
v5.4.3.201909031940-r
v5.5.0.201908280940-m3
v5.5.0.201909041048-rc1
v5.5.0.201909110433-r
v5.5.1.201910021850-r
v5.6.0.201911271000-m3
v5.6.0.201912041214-rc1
v5.6.0.201912101111-r
v5.6.1.202002131546-r
v5.7.0.202001151323-m1
v5.7.0.202002241735-m3
v5.7.0.202003090808-r
v5.7.0.202003110725-r
v5.8.0.202005061305-m2
v5.8.0.202006091008-r
v5.8.1.202007141445-r
${ noResults }
6 Commits (master)
Author | SHA1 | Message | Date |
---|---|---|---|
Han-Wen Nienhuys | c217d33ff8 |
Documentation/technical/reftable: improve repo layout
Previously, the list of tables was in .git/refs. This makes repo detection fail in older clients, which is undesirable. This is proposal was discussed and approved on the git@vger list at https://lore.kernel.org/git/CAFQ2z_PvKiz==GyS6J1H1uG0FRPL86JvDj+LjX1We4-yCSVQ+g@mail.gmail.com/ For backward compatibility, JGit could detect a file under .git/refs and use it as a reftable list. Change-Id: Ic0b974fa250cfa905463b811957e2a4fdd7bbc6b Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> |
5 years ago |
Han-Wen Nienhuys | 7c75a68b96 |
reftable: enforce ascending order in sortAndWriteRefs
MergedReftableTest#scanDuplicates tests whether we can write duplicate keys in a merged reftable. Apparently, the first key appearing should get precedence, and this works because the sort() algorithm on ordered collections is stable. This is potentially confusing behavior, because you can write data into the table that cannot be retrieved (Merged table can only have one entry per key), and the APIs such as exactRef() only return a single value. Make this consistent with behavior introduced in I04f55c481 "reftable: enforce ordering for ref and log writes" by considering a duplicate key in sortAndWriteRefs as a fatal runtime error. Change-Id: I1eedd18f028180069f78c5c467169dcfe1521157 Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> |
5 years ago |
Han-Wen Nienhuys | cf11a03bc2 |
Documentation/technical/reftable: change suggested file names
By using ${min_update}-${max_update} as file name template, we guarantee that each file has a unique name. This allows data from open files to be cached across reloads of the stack. This is in anticipation of Change I1837f268e ("file: implement FileReftableDatabase"), which is the first implementation of reftable on a filesystem. Change-Id: I7ef0610eb60c494165382d0c372afcf41f074393 Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> |
5 years ago |
Han-Wen Nienhuys | c517725b8c |
Documentation/technical/reftable: document rename in reflog.
Change-Id: I0fe7d28a772b1ee9eefd9a38bff5e08a8559988f Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> |
5 years ago |
Shawn Pearce | 44a75d9ea8 |
reftable: explicitly store update_index per ref
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 |
7 years ago |
Shawn Pearce | b9e818b556 |
reftable: file format documentation
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 |
7 years ago |