Каковы пределы файла в Мерзавце (число и размер)?

Question

Каковы пределы файла в Мерзавце (число и размер)?

В Clearcase возьмите спецификацию конфигурации и добавьте:

time  <date-time>
<rules for choosing branches or labels>
end time

Сделайте второй вид и сравните их. Если несколько разработчиков работают над одними и теми же файлами, я понятия не имею. Я не могу сказать, что я в восторге от использования Clearcase, когда-либо.

170

git

задан VonC 11 June 2014 в 04:48

5 ответов

Реального ограничения нет - все имеет 160-битное имя. Размер файла должен быть представлен в виде 64-битного числа, так что и здесь нет никакого реального ограничения.

Однако есть практическое ограничение. У меня есть репозиторий размером ~ 8 ГБ с> 880 000, и git gc занимает некоторое время. Рабочее дерево довольно большое, поэтому операции по проверке всего рабочего каталога занимают довольно много времени. Однако это репо используется только для хранения данных, так что это просто набор автоматизированных инструментов, которые его обрабатывают. Получение изменений из репозитория намного быстрее, чем синхронизация тех же данных.

%find . -type f | wc -l
791887
%time git add .
git add .  6.48s user 13.53s system 55% cpu 36.121 total
%time git status
# On branch master
nothing to commit (working directory clean)
git status  0.00s user 0.01s system 0% cpu 47.169 total
%du -sh .
29G     .
%cd .git
%du -sh .
7.9G    .

32

ответ дан 23 November 2019 в 20:48

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

Нет ' Тем не менее, эта модель действительно ограничена. Вы, конечно, можете использовать его плохо и быть несчастным.

3

ответ дан 23 November 2019 в 20:48

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

1

ответ дан 23 November 2019 в 20:48

Вы можете попробовать распознать постфиксы:

Mapper.Initialize(cfg => {
    cfg.RecognizePostfixes("Field");
    cfg.CreateMap<Source, Dest>();
});

Распознавание префиксов также работает локально по отношению к профилям, если это просто набор карт, к которым это относится.

-121--2560816-

или из командной строки VS типа «tf changeset 1234» (убедитесь, что ваша корневая папка находится внутри рабочей области или вам придется явно определить командный проект и т.д.)

-121--1321918-

Если вы добавляете слишком большие файлы (ГБ в моем случае, Cygwin, XP, 3 ГБ оперативной памяти), ожидайте этого.

fatal: Не хватает памяти, malloc не удалось

Подробнее здесь

Update 3/2/11: Saw аналогичные в Windows 7 x64 с Tortoise Git. Тонны используемой памяти, очень медленный отклик системы.

28

ответ дан 23 November 2019 в 20:48

Другие вопросы по тегам:

git

Похожие вопросы:

score 157 · Accepted Answer

Это сообщение от Линуса может помочь вам с некоторыми другими ограничениями

[...] CVS, т.е. он действительно в значительной степени ориентирован на "один файл за один раз ».

Что приятно тем, что у вас может быть миллион файлов, а затем проверять только некоторые из них - вы даже никогда не увидите влияние другого 999 995 файлов.

Git принципиально никогда не смотрит на меньше, чем на все репо. Даже если ты немного ограничить вещи (например, проверить только часть или оставить историю немного назад), git по-прежнему всегда заботится обо всем,

Итак, git очень плохо масштабируется, если вы заставляете его смотреть на все как на единое целое. огромный репозиторий. Я не думаю, что это действительно поправимо, хотя мы возможно, можно улучшить его.

И да, еще есть проблемы с "большим файлом". Я действительно не знаю что делать с огромными файлами. Я знаю, что мы их обижаем.

Подробнее см. В моем другом ответе : ограничение с Git состоит в том, что каждый репозиторий должен представлять « согласованный набор файлов », «всю систему» сама по себе (вы можете без тега "часть репозитория").
Если ваша система состоит из автономных (но взаимозависимых) частей, вы должны использовать субмодулей .

Как показано в ответе Таллджо , пределом может быть система один (большое количество файлов), но если вы действительно понимаете природу Git (о согласованности данных, представленной его ключами SHA-1), вы поймете, что истинный «предел» - это использование one: т.е. вам не следует пытаться хранить все в репозитории Git, если только вы не готовы всегда получать или отмечать все обратно. Для некоторых крупных проектов это не имело бы смысла.

Для более подробного изучения ограничений git см. « git с большими файлами »
(в котором упоминается git-lfs : решение для хранения больших файлов вне репозитория git. GitHub, апрель 2015 г.)

Три проблемы, ограничивающие репозиторий git:

огромные файлы ( xdelta для файла пакета находится только в памяти, что не очень хорошо для больших файлов)
огромное количество файлов , что означает один файл на большой двоичный объект и медленный git gc для создания одного packfile за раз.
огромные файлы packfiles с индексом packfile, неэффективным для извлечения данных из (огромного) файла packfile.

Более свежий поток (февраль 2015 г.) иллюстрирует ограничивающие факторы для Git repo :

Будет ли несколько одновременных клонов с центрального сервера замедлять другие параллельные операции для других пользователей?

При клонировании сервер не блокируется, поэтому теоретически клонирование не влияет на другие операции.Клонирование может использовать много памяти (и много процессора, если вы не включите функцию растрового изображения достижимости, что вам следует).

Будет ли ' git pull ' медленным?

Если мы исключим на стороне сервера, размер вашего дерева является основным фактором , но ваши 25k файлов должны быть в порядке (linux имеет 48k файлов).

' git push '?

На это не влияет глубина истории вашего репо или ширина вашего дерева, поэтому следует действовать быстро ..

Ах, количество ссылок может повлиять как на git-push , так и на git-pull .
размер вашего дерева является основным фактором , но ваших 25k файлов должно хватить (linux имеет 48k файлов).

' git push '?

Это не зависит от того, насколько глубока история вашего репо или насколько велико ваше дерево, поэтому следует действовать быстро ..

Ах, количество ссылок может повлиять на git-push и git-pull .
размер вашего дерева является основным фактором , но ваших 25k файлов должно хватить (linux имеет 48k файлов).

' git push '?

Это не зависит от того, насколько глубока история вашего репо или насколько велико ваше дерево, поэтому следует действовать быстро ..

Ах, количество ссылок может повлиять на git-push и git-pull .
Я думаю, что Стефан лучше меня знает в этой области.

' git commit '? (Он указан как медленный в ссылка 3 .) ' git status '? (Снова медленно в ссылке 3, хотя я этого не вижу.)
(также git-add )

Опять же, размер вашего дерева. Учитывая размер вашего репо, я не думаю, что вам стоит об этом беспокоиться.

Некоторые операции могут показаться не повседневными, но если они часто вызываются веб-интерфейсом GitLab / Stash / GitHub и т.д., тогда они могут стать узкими местами. (например, ' git branch --contains ' кажется ужасно неблагоприятным из-за большого количества ветвей.)

git-blame может работать медленно, когда файл сильно изменяется.