Hi, On Fri, 7 Aug 2009, Sam Vilain wrote: > Johannes Schindelin wrote: > >> the short answer is that cache slices are totally independant of pack > >> files. > >> > > > > My idea with that was that you already have a SHA-1 map in the pack > > index, and if all you want to be able to accelerate the revision > > walker, you'd probably need something that adds yet another mapping, > > from commit to parents and tree, and from tree to sub-tree and blob > > (so you can avoid unpacking commit and tree objects). > > > > Tying indexes together like that is not a good idea in the database > world. This is not the same index as in the database world. It is more comparable with a cached view. And there, it is generally a good idea to keep related things in the same cached view (with an outer join), rather than having two primary keys for almost every record. > Especially as in this case as Nick mentions, the domain is subtly > different (ie pack vs dag). Unfortunately you just can't try to pretend > that they will always be the same; you can't force a full repack on > every ref change! No, but you do not need that, either. In the setting that is most likely the most thankful one, i.e. a git:// server, you _want_ to keep the repository "as packed as possible", otherwise the rev cache improvements will be lost in the bad packing performance anyway. > > Still, there is some redundancy between the pack index and your cache, > > as you have to write out the whole list of SHA-1s all over again. I > > guess it is time to look at the code instead of asking stupid > > questions. > > > > "Disk is cheap" :-) Disk I/O ain't. (Size of the I/O caches, yaddayadda, I'm sure you get my point). Ciao, Dscho -- 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