1.1, segesg (?), 14:46, 08/06/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
Народ, какой максимальный размер репы git с которой вам приходилось работать?
У меня на 10Gb начинал притормаживать.
| |
|
2.2, Аноним (2), 15:01, 08/06/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Просто для информации: по опыту, на винде работает на порядки медленнее, чем на линуксе. Возможно, проблема может быть в этом.
| |
|
3.3, Иваныч (??), 16:46, 08/06/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Там где есть много внешних вызовов падение производительности весьма заметное. Я недавно заменил tr, который использовался для проведения всего в нижний регистр, на встроенную команду от bash и прирост был около 2-х раз. Тоже касается команд для определения имени и деректории, в итоге скорость sh скрипта стала сопоставима с Linux окружением. С 15-ти минут к 20 секундам, в соотношении с 15 секундам на Linux.
| |
|
2.4, Додо (?), 20:49, 08/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
А на кой вам 10 гигабайт хранить в репозитории?
Если он увеличился до подобных размеров - наверное, есть смысл разбить на несколько отдельных репозиториев?
| |
|
3.6, Аноним (6), 23:36, 08/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Не знаю как у топик стартера, но я видел уникомов, которые хранили с vcs результаты компиляции (объектники, exe-шники и пр.). Для небольших проектов размеры репы доходили до 300-500 мегабайт.
| |
|
4.19, Аноним (19), 21:39, 09/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
А сожалению есть популярные репозитории, хранящие всю многогиговую историю. По-моему, единственное, что тут нужно сделать - это заморозить кодовую базу в смысле "не принимаем новые фичи в этот репозиторий", отребейзить все неслитые ветки, включая PR, на macter, пофиксить, перезаписывая историю, после чего cкопировать рабочую копию в новую папку и создать новый репозиторий. Старый переименовать в old-0, в initial commite дат ссылку на него. Пересоздать все ветки. Должно сильно уменьшить объём.
| |
|
5.25, Аноним (25), 19:07, 10/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Зачем терять историю? Пускай себе лежит. Можно просто при клонировании глубину указывать, чтобы не тянуть ненужное.
| |
|
6.26, Аноним (26), 12:09, 11/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Можно просто при клонировании глубину указывать, чтобы не тянуть ненужное
Это всё рано стянет ненужное, если хоть маленький кусочек старья по-прежнему используется.
| |
|
7.27, Аноним (27), 14:40, 15/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Стянет ровно столько, сколько попросишь, не больше и не меньше. Иди читай, как git работает.
| |
|
|
|
|
|
2.7, segesg (?), 23:42, 08/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Минусующие такие минусующие)
Мусора в репе нет, про ингнор в курсе
С Windows не работал уже лет 10 наверное
Делить по ряду причин неудобно, там другие проблемы вылазят
Видимо тут никто с реально большими репами не работал, ну да ладно
| |
|
3.8, KonstantinB (ok), 00:22, 09/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Да понятно что будет тормозить.
Надо делить на модули/пакеты - либо стандартными для используемого стека средствами, либо, на худой конец, через сабмодули. Да, для легаси это тяжело и болезненно, но никуда не денешься, придется рано или поздно.
| |
3.9, Crazy Alex (ok), 00:27, 09/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну порядка гига репа совершенно нормально себя чувствует... правда, на ssd. С бОльшими не работал.
| |
|
4.13, без имени (?), 12:24, 09/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
скорее всего ключевое слово здесь SSD - аналогично 12 гигов репа (размер .git директории) работает нормально на SSD, на харде эта же репа заметно притормаживает на больших операциях
| |
|
|
2.10, Аноним (27), 08:17, 09/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
Не понял — репа 10Г или отдельно взятый срез 10Г? Если второе, ты явно что-то делаешь не так. Если первое — не припоминаю, чтобы с таким сталкивался, но в пределах 1-2Г тормозов не наблюдал (хотя в тех случаях тоже многое делалось не так).
| |
2.11, .anonymous (?), 11:01, 09/06/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Под "репой" имеется в виду ".git" или содержимое репозитория на последнем commit-е? Если первое, и если я правильно помню (но могу ошибаться), то гигов 100. Работало нормально.
| |
|
3.20, segesg (?), 22:54, 09/06/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Во, это уже тема!
Речь про сумму .git и полного чекаута - т.к. с репой надо ещё и работать.
Можно поинтересоваться сколько примерно в вашей репе объектов, сколько времени длится коммит и rebase, и сколько клиентов тянет сервер?
| |
|
4.24, Аноним (27), 08:35, 10/06/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Речь про сумму .git и полного чекаута - т.к. с репой надо ещё и работать.
Соотношение-то какое? Если у тебя там огромные объекты, git будет тормозить, потому что он так устроен, а ты используешь его не по назначению. Если просто очень много объектов в истории, особых тормозов быть не должно.
| |
|
|
|
|
2.22, Аноним (27), 00:25, 10/06/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Добавлена опциональная возможность применения алгоритма хэширования SHA-256 вместо скомпрометированного SHA-1 при сборке Git в режиме "NewHash". Код для обхода дерева объектов изменён с учётом того, что имена объектов могут вычисляться не только с использованием SHA-1.
https://www.opennet.dev/opennews/art.shtml?num=50202
| |
|
|