That would work, but I sorta like the idea of caching the actual names. I'm thinking of having a block of slice-unique, null-seperated names at the end of each slice (ie. not in the mapping) which is loaded into memory (it wouldn't be very big). Then each blob/tree object would have an variable length index referencing a particular name. Using the actual names would give us greater flexbility, and allow rev-cache to output proper rev-list type output (with the names after the hashes). On Fri, Aug 7, 2009 at 1:43 AM, A Large Angry SCM<gitzilla@xxxxxxxxx> wrote: > Shawn O. Pearce wrote: >> >> A Large Angry SCM <gitzilla@xxxxxxxxx> wrote: >>> >>> Shawn O. Pearce wrote: >>>> >>>> Nick Edelen <sirnot@xxxxxxxxx> wrote: >>>>> >>>>> Hrmm, I just realized that it dosn't actually cache paths/names... >>>> >>>> You may not need the path name, but instead the hash value that >>>> pack-objects computes from the path name. >>> >>> Please do NOT expose the hash values. The hash used by pack-objects is >>> an implementation detail of the heuristics used by the _current_ object >>> packing code. It would be a real shame to have to maintain backward >>> compatibility with it at some future date after the packing machinery has >>> changed. >> >> This is a local cache. If there was a version number in the header, >> and the hash function changes, we could just bump the version number >> and invalidate all of the caches. >> >> No sense in storing (and doing IO of) huge duplicate string values >> for something where we really only need 32 bits, and where a >> recompute from scratch only costs a minute. >> > > That will work for me if the cache gets a version number and iff the > pack-objects hash code gets big warning comments about the cache code > dependency. > -- 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