Bundle-URI on fetch / resume-able clone ======================================= (moderator: Toon; notetaker: Taylor) * Toon: we have bundle-uris, which allow us to download bundles before cloning. What would it take to do them on fetch, too? * Toon: Complex; you might end up downloading a lot of bundles that you don't need. * Toon: there was a bundle token that could be used by the client to determine whether or not it needs the bundle. Unfortunately, since you don't know what amount of history you're missing, the bundle in and of itself may not be sufficient. * Toon: How do we make bundles more efficient on fetch and aware of what the clients do and don't have. * Johannes: In VFS for Git, the set of bundles is "opinionated" and regenerated often (e.g., weekly, daily, hourly, etc.). We don't really care about oversharing, because it's fast enough to download those static files. * Toon: That's true for the server, not for a singular client. * Johannes: right, but it's to protect the server. If you don't care about having too-big of a bundle, it's OK because you can just fetch the last hour and then see what you still need on top of that. * Johannes: there is logic to determine what you need to download based on the time that you last fetched, etc. * Elijah: are they thin packs? Yes. * Patrick: the heuristics that we have to advertise what kind of bundles are on the server is not sufficient enough to determine which bundles the client may or may not want to download. The client must guess. * Jonathan: ISTM that the property list for the bundles as they are today should probably be considered a starting point (as in "part of a feature"). The heuristics need to be extended. * Jonathan: at Google we use packfile-URIs, and one of the advantages of how that works is that since the packfiles are advertised after the normal fetch negotiation, you get a curated list. For bundle-uris, need something analogous to the fetch negotiation for the client to be able to make a similar decision of which bundle to download. * brian: extending the feature to store timestamps, then you could store the last fetch on the system would inform some better selection of which bundles to clone down during a fetch. * brian: Would make a big difference for folks in environments which do not benefit from reliable Internet connections. * Toon: Sure... but you have to put a lot of pressure to keep those bundles up-to-date on the server side. * Jonathan: one of the advantages of bundles over packs is that they have information about the references. One potential property could be "here's the length of this header" and then having the client download it to examine whether or not it wants such a bundle. * Patrick: probably would want to cache those on the client so that we're able to avoid re-downloading these every single time. * Toon: resumability * Jonathan: protocol supports it, just hasn't been implemented. Someone needs to just get it done. :) * Beyond that, the main complication is how you store the state and what the UX is for resuming. But a person implementing it can figure those things out. * Brian: broken-proxy situations require some configurability of where your bundles can be downloaded from.
