Shawn Pearce <spearce@xxxxxxxxxxx> writes: > On Fri, Nov 4, 2011 at 02:35, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: > > Am 11/4/2011 9:56, schrieb Clemens Buchacher: > > > Cache ... not the pack but the information > > > to re-create it... > > > > It has been discussed. It doesn't work. Because with threaded pack > > generation, the resulting pack is not deterministic. > > The information to create a pack for a repository with 2M objects > (e.g. Linux kernel tree) is *at least* 152M of data. This is just a > first order approximation of what it takes to write out the 2M SHA-1s, > along with say a 4 byte length so you can find given an offset > provided by the client roughly where to resumse in the object stream. > This is like 25% of the pack size itself. Ouch. Well, perhaps caching a few most popular packs in some kind of cache (packfile is saved to disk as it is streamed if we detect that it will be large), indexing by WANT / HAVE? > This data is still insufficient to resume from. A correct solution > would allow you to resume in the middle of an object, which means we > also need to store some sort of indicator of which representation was > chosen from an existing pack file for object reuse. Which adds more > data to the stream. And then there is the not so simple problem of how > to resume in the middle of an object that was being recompressed on > the fly, such as a large loose object. Well, so you wouldn't be able to just concatenate packs^W received data. Still it should be possible to "repair" halfway downloaded partial pack... Just my 2 eurocents^W groszy. -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html