Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: >> FWIW, I wasn't thinking about GC and expiration. If bundle URI >> thing can say "you need this, that and that other bundle" and cause >> you to fetch three bundles, I thought that there needs a way for you >> to record the tips of these three bundles---these three bundles >> should not have to compete for refs/bundles/master, for example. > > Not wanting to compete makes sense, but also we should usually > expect the "most recent" bundle to be the most recent version of the > branch. However, that ordering only makes sense when we have the > creationToken (nee timestamp) heuristic, so having distinct ref > spaces makes sense to avoid collisions. I still do not see how keeping track of bundle tips in the longer term with refs fits in the larger picture. It's not like we are keeping the bundle files (we are instead exploding them into the object store, at which point the contents are mixed with all other objects), and if we do so as part of a boot-strapping, we'd fetch more history on top of what came from bundles, at which point we no longer need these refs for protecting objects from collection. And if the project rewinds and force pushes history, some objects that originally came from these bundles can and should go stale and be collected. Also, if I am not mistaken, the table of contents does not record the tip commits of each bundle, so keeping track of the bundle tips we have seen does not help us optimizing download upon seeing a toc---we'd need to look at the bundle data (at least the header part that lists the tips) anyway. Not complaining against the existence of refs/bundles/ hierarchy. Just stating that I do not think I got the use of it documented in the proposed design (perhaps it was described but I didn't understand it, or perhaps it was under-described and needs clarification). Thanks.
