On Mon, 26 Nov 2007, Dana How wrote: > Currently data can be quickly copied from pack to pack, > but data cannot be quickly copied blob->pack or pack->blob I don't see why you would need the pack->blob copy normally. > (there was an alternate blob format that supported this, > but it was deprecated). Using the pack format for blobs > would fix this. Then you can do just that for big enough blobs where "big enough" is configurable: encapsulate them in a pack instead of a loose object. Problem solved. Sure you'll end up with a bunch of packs containing only one blob object, but given that those blobs are so large to be a problem in your work flow when written out as loose objects, then they certainly must be few enough not to cause an explosion in the number of packs. > It would also mean blobs wouldn't need to > be uncompressed to get the blob type or size I believe. They already don't. > So far this has prevented me from deploying git here > (and is half the reason I have not been active recently). > Currently we use p4 and we have large files. > When a large file is checked in (submitted), > it is compressed *once* and sent over the network -- > these are the only delays that end-users experience. > > The equivalent operation in git would require the creation of > the blob, and then of a temporary pack to send to the server. > This requires 3 calls to zlib for each blob, which for very > large files is not acceptable at my site. I currently count 2 calls to zlib, not 3. And with big blobs as packs, as suggested above then you'd have only one call when actually staging their content. This should be really straight forward to implement given that pack-objects is already a built-in. Nicolas - 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
