On Tue, Sep 21, 2010 at 10:32 PM, Abhijit Menon-Sen <a...@toroid.org> wrote:
> That's not it. I ran the same git gc command on my old repository, and > it didn't make any difference to the size. (I didn't try with a larger > window size, though.) Probably lots of it has to do with the delta chains themselves. The old repository was an "incremental" conversion, so each new delta (as it's added) has only (and all) "repository wide" objects to look at for choosing a base. git has some limits and hueristics on deciding "how far and wide" to look for the best delta base. The cvs2* scripts are more direct, they first reference the files, then commit graph, etc, so all revisions of a particular file are added before moving on to the next. This means that all previous versions of a file are likely "hot" in the path git will look for the best fit delta. By changing the order of how the objects are added to the git repository, it makes it easier for git to find the best/better delta bases. You can adjust the "delta window" git-repack uses, see the man page for git-repack, and git-gc. If you're willing to do a monster repack on the old repository (using a *huge* window) you can likely get it close in size. a. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
