Hello,
On 04/11/2010 04:50 AM, Nicolas Pitre wrote:
core.deltaBaseCacheLimit. Given that your files are "relatively" small
i.e. in the 4MB range max, then the cache should be able to hold quite
many of them. At the moment with its 16MB limit, only a few of those
objects would evict many objects from the cache quickly.
If this is still not good enough, then you could add a negative delta
attribute to those large binary files (see
http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html)
and repack the repository on the server. Of course that will make the
repository larger and the data transfer longer when cloning, but the
"resolving deltas" will be much faster. This is therefore a tradeoff.
Another solution which might be way more practical for users of such a
huge repository is simply to use a shallow clone. Surely those people
cloning this repository might not need the full history of the
repository. So you could simply use:
git clone --depth=10 ...
and have only the last 10 revisions transferred. Later on the
repository can be deepened by passing the --depth argument with a larger
value to the fetch command if need be.
Nicolas
Thanks for comprehensive answer, Nicolas. Now I see 3 directions to work
on: cacheLimit, negative delta attributes and shortening the history
(actually, I don't think "clone --depth" is feasible in our environment,
but we can try to backup and just purge the history).
--
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