Как хранилище Mercurial растет со временем? - PullRequest
7 голосов
/ 29 октября 2010

Допустим, я создал репозиторий, добавил к нему x файлы и зафиксировал. Скажем, размер a Мб после первоначальной фиксации.

  • Есть ли способ оценить, насколько большим будет хранилище через один год?

  • Если количество строк кода увеличилось на 10%, увеличится ли хранилище соответственно?

  • Как количество коммитов, веток, тегов и т. Д. Влияет на размер хранилища?

  • Будет ли 10000 коммитов в том же году увеличивать хранилище (заметно) более, чем, скажем, 1000 коммитов?

  • Может быть, мой вопрос сформулирован неправильно?

Ответы [ 4 ]

5 голосов
/ 29 октября 2010

Изменения в хранилище Mercurial сохраняются как полный файл или как сжатая дельта относительно предыдущей версии:

https://www.mercurial -scm.org / wiki / FAQ # FAQ.2BAC8-TechnicalDetails.How_does_Mercurial_store_its_data.3F

Mercurial принимает решение о том, сохранять ли полный файл по сравнению с дельтой, основываясь на количестве внесенных изменений.

Это означает, что это не просто добавление строккода, который увеличит общий размер репозитория, но также:

  1. Количество изменений, внесенных в существующий код.
  2. Количество изменений, внесенных в каждый файл за фиксацию.
  3. Количество файлов, которые добавляются и впоследствии удаляются.

Mercurial сохраняет все удаленные файлы.Вы можете добавить файл размером 1 ГБ в свой репозиторий и затем удалить его;количество строк не увеличилось, но поскольку файл остается в хранилище, хранилище будет значительно больше.

Чтобы ответить на ваши вопросы по очереди:

  • Я полагаю, что можно приблизительно оценить размер хранилища через x месяцев, предполагая, что вы в целом сохраняете постоянную скорость изменения хранилища (т.е. вы добавляете / удаляете / изменяете файлы с той же скоростью, изменяя примерно одинаковое числострок на коммит).

  • Увеличение количества строк кода на 10% не говорит нам, сколько строк было удалено / изменено, поэтому увеличение количества строк кода выиграло 't обязательно соответствуют тому же увеличению размера репо.

  • Теги не влияют на размер репо Mercurial более чем на несколько байтов.Также не делайте ветки, пока вы не начнете работать с ними, и в этот момент они добавляют те же накладные расходы, что и работа над подсказкой.Количество коммитов должно быть разумно пропорционально размеру репо, при условии, что происходит одинаковая скорость изменения.

  • Фиксация 10x, как часто, вероятно, не увеличит размер файла, так как это скоростьизменений, которые оказывают основное влияние на размер репо, а не на количество коммитов.

3 голосов
/ 29 октября 2010

Прямая оценка размера за год, очевидно, невозможна, если у вас нет представления о количестве коммитов и окончательном размере рабочего дерева.

Тем не менее, git довольно эффективно использует дисковое пространство. Абсолютно никогда не хранится более одной копии данной версии файла (это внутренне представляется в виде большого двоичного объекта), а старые большие двоичные объекты дельта-сжимаются в пакеты. Это означает, что он очень эффективен для хранения простого текста и очень неэффективен для больших двоичных файлов. Если ваш проект в основном простой текст, вам почти наверняка не о чем беспокоиться.

Ветви и теги практически не влияют на размер. Конечно, ветвь reflog может составить несколько КБ, но это не о чем беспокоиться. Облегченные теги - это просто сохраненный SHA1, а аннотированные теги просто добавляют к этому метаданные.

Что касается строк кода и количества коммитов, сложно сказать точно. Вообще, коммиты - это гораздо больший фактор, чем строки кода; у вас может быть много разных версий файлов, которые все складываются (даже представлены в виде дельт), но фактическое содержимое должно быть сохранено только один раз. Это подтверждается тем фактом, что рабочие деревья имеют тенденцию быть намного больше, чем каталог .git. Например, мой клон git.git имеет рабочее дерево 17 МБ и каталог .git 39 МБ. Другие проекты, которые я исследовал, имели аналогичные отношения.

Больше коммитов равного размера , безусловно, увеличит хранилище, но если взять 1000 коммитов и разбить их на 10000 (включая те же изменения), это не сделает хранилище намного больше. Сами объекты коммита малы; это различия в файлах, которые занимают место. Вы можете увидеть начальный всплеск размера, поскольку коммиты только периодически подвергаются дельта-сжатию, но как только срабатывает git gc --auto, эти коммиты сжимаются обратно.

Лучшее обобщение, которое я могу сделать, заключается в том, что каталог .git хранилища будет стремиться расти со скоростью , пропорциональной количеству дельты за время, что в целом должно быть пропорционально размеру рабочего дерева и Скорость, с которой люди модифицируют проект. Это, конечно, настолько общий вопрос, что может быть совершенно бесполезным, но вы здесь.

Если вы хотите оценить, я просто взял бы некоторые данные за первый месяц или около того, и попытался бы построить кривую.

1 голос
/ 29 октября 2010

Взгляните на страницу GitBenchmarks на вики-сайте Git, раздел «Тесты размера репозитория» и «Другие тесты и ссылки» (принимая во внимание при тесте производительности, и какие версии используются), в частности запись на конечной странице:

  • Обзор DVCS: одна система, чтобы управлять ими всеми? - Часть 3 Роберта Фендта (Robert Fendt), посвященная Linux Developer Network, от 27-01-2009, содержит результаты двух синтетических тестов производительности, показывающих, как система работает в условиях стресса (количество коммитов в репозитории или количество выполненных файлов).

    В качестве тестовой системы использовалась виртуальная машина под управлением Ubuntu 8.10, и использовались следующие версии программного обеспечения: SVK 2.0.2 (последняя - 2.2.3), darcs 2.1.0 (последняя - 2.4.4), монотонная 0,42 (последняя - 0,48). , Bazaar 1.10 (последний 2.2.1 ), Mercurial 1.1.2 (последний 1.6.4) и Git 1.6.1 (последний 1.7.3).

0 голосов
/ 29 октября 2010

Если вы беспокоитесь о размерах грибов, зайдите и клонируйте некоторые онлайн-проекты и изучите размер их репозиториев.Есть много крупных проектов на выбор с коммитами веток и т. Д., И т. Д. Мой опыт показывает, что git & mercurial и довольно хорошо справляется с уменьшением размера, размер отражает больше файлов, которые вы в них помещаете (и их размер), а не накладные расходы.

...