Re: repository size differences

Поиск
Список
Период
Сортировка
От Aidan Van Dyk
Тема Re: repository size differences
Дата
Msg-id AANLkTinoW+CKaOc_A5PMGdhRAFns6VeYPxJARi8QY+cH@mail.gmail.com
обсуждение исходный текст
Ответ на Re: repository size differences  (Abhijit Menon-Sen <ams@toroid.org>)
Список pgsql-hackers
On Tue, Sep 21, 2010 at 10:32 PM, Abhijit Menon-Sen <ams@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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Standby registration
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Git cvsserver serious issue