| 1 |
On Tue, 27 Nov 2018 16:01:15 -0500 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> Our repo is a linked list being constantly manipulated from the head |
| 5 |
> backed by a hashed object store for the contents. For that use case |
| 6 |
> it is probably the ideal data structure. Since our use case is |
| 7 |
> actually the typical use case, it isn't a surprise that this was the |
| 8 |
> design that was chosen... :) |
| 9 |
> |
| 10 |
> Computers are pretty fast when you actually use the correct algorithm... |
| 11 |
|
| 12 |
There's more to it than that. If that was all it was, then imagine if |
| 13 |
it wasn't for all the compression and differencing tricks. |
| 14 |
|
| 15 |
The raw size of an uncompressed verbatim, undifferential repository for |
| 16 |
Gentoo would be phenomenal. |
| 17 |
|
| 18 |
As it is, its fortunate we don't do a lot of things that *need* raw |
| 19 |
access to non-tip commits, because doing so becomes very exhausting. |
| 20 |
|
| 21 |
And were it not for its compression techniques and the fact our use of |
| 22 |
Portage results in a vast number of highly-self-similar entries, then |
| 23 |
we'd likely be slaughtered by disk IO alone, regardless of the linked |
| 24 |
list approach. |
| 25 |
|
| 26 |
Just don't try using filter branch on a whole gentoo repository, you'll |
| 27 |
quickly learn why. ( You'll find yourself having to employ lots of |
| 28 |
tricks with git fast-export instead just to avoid projected times in |
| 29 |
weeks ) |
Archives