Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 64
В общем, разработчики из Facebook намекают на то, что хорошо бы переписать Git для улучшения производительности. Разделить репозиторий на несколько частейОсобенно доставило.они отказываются.
Как буд-то git и компания им чего-то должны.
Ну вот пусть и перепишут)
Это очень хорошо, когда даже в связи с возникшими проблемами крупная компания продолжает поддерживать open-source разработки
Особенно доставило, что вы делаете выводы по пересказу письма.
Фейсбуковцы ни на что не намекали, а спросили совета в какую сторону им двигаться дальше для увеличения производительности.
Фейсбуковцы ни на что не намекали, а спросили совета в какую сторону им двигаться дальше для увеличения производительности.
Ни чего не скажешь, норм так ребята git хотят припахать…
Одно должно радовать простых пользователей — для Git эта история должна закончится положительно, и он будет модифицирован в лучшую сторону. Даже если это не произойдёт с его основной веткой, то скорее всего будет Fork…
Одно должно радовать простых пользователей — для Git эта история должна закончится положительно, и он будет модифицирован в лучшую сторону. Даже если это не произойдёт с его основной веткой, то скорее всего будет Fork…
Вы нифига не поняли из написанного. Или специально несёте ахинею.
Речь шла об исключительно синтетических тестах.
Речь шла об исключительно синтетических тестах.
не совсем понятно, зачем хранить коммиты 2х-3х годичной давности
можно ж вынести их в отдельные архивные репозитарии, а в основном — отсечь
вобщем, фб сам себе проблемы выдумал
можно ж вынести их в отдельные архивные репозитарии, а в основном — отсечь
вобщем, фб сам себе проблемы выдумал
Количество файлов от этого не уменьшится.
Кстати, они не отказываются разбивать репозитарии на несколько, там, где это возможно:
Кстати, они не отказываются разбивать репозитарии на несколько, там, где это возможно:
We already have some of the easily separable projects in separate repositories, like HPHP. If we could split our largest repos into multiple ones, that would help the scaling issue. However, the code in those repos is rather interdependent and webelieve it'd hurt more than help to split it up, at least for the medium-term future.
Каждый год-два грохать всю историю — вот это костыли
Непонятно скорее зачем выносить коммиты в отдельные архивные репозитории, если проблем в основном они не доставляют.
К предыдущим каментам: в принципе Facebook'овцы в чем то правы. Мы все помним такие заявления как «640КБ должно быть достаточно для каждого» и историю с IPv4. Кто знает насколько вырастет код чкрез ~3 года?
Проблемы с производительностью пищеварительного тракта при поедании 500кг ветчины.
В какабуке, просто глупизной занимаются.
Вот бы Торвальдс почитал.
Это ж просто надо быть без соображалки, чтобы держать актуальными 4 ляма коммитов.
Он бы почитал, как устроена работа в ядре линукса. Там коммитеров, еще больше чем в какабуке, и никто такой дури не писал.
Видимо, этот дядька, зазнался, находясь в какабуке и решил с вершины своей чето крикнуть.
Вот бы Торвальдс почитал.
Это ж просто надо быть без соображалки, чтобы держать актуальными 4 ляма коммитов.
Он бы почитал, как устроена работа в ядре линукса. Там коммитеров, еще больше чем в какабуке, и никто такой дури не писал.
Видимо, этот дядька, зазнался, находясь в какабуке и решил с вершины своей чето крикнуть.
Опять попался. Написал коммент в топик от Ализара.
Ализар, хватит желтуху писать в хабр. Ценности никакой, кроме флуда для народа.
Ализар, хватит желтуху писать в хабр. Ценности никакой, кроме флуда для народа.
Проблемы с производительностью есть и на гораздо меньших репозиториях, git status в полминуты на холодном — напрягает.
Вот бы они производительность других систем проверили.
Интересно, а кто-нибудь подобные тесты для SVN проводил? Что там будет?
Скрипт для создания тестового репозитария запущен, через пару столетий можно будет протестить.
И еще бы про hg
Тоже было бы интересно почитать. Когда нас сподвигали перевести основные проекты с svn на git, нам пели интересные песни о том, как всё станет быстрее и лучше, особенно на операциях типа статус и прочих синхронизациях с репозиториями («ведь репы локальные!»). Увы, не стало почему-то. Что-то стало лучше и удобнее, что-то доставляет неудобства, но скорости не очень заметно. Может, мы чего-то не то делаем?
Винда?
Винда?Догадка неверна, винды на рабочих станциях у нас нет ни одной. У меня линуксы. Федора, арч. А что не так с виндой в этом плане? Ну и нет чтобы посоветовать чего, сразу запинали :(
Под виндой очень сильно тормозит беганье по дереву директорий.
Если у вас есть конкретный вопрос — то попрошу полный вывод всего перечисленного:
На каких командах и какие тормоза?
я не помню чтоб локальные (git status, git diff) итд у меня тормозили, но у меня и проекты мелки, до 300 метров репа.
Если у вас есть конкретный вопрос — то попрошу полный вывод всего перечисленного:
du -hs . .git
git --version
git repack
df -Th .
free
На каких командах и какие тормоза?
я не помню чтоб локальные (git status, git diff) итд у меня тормозили, но у меня и проекты мелки, до 300 метров репа.
Разная степень тормозов, в зависимости от метода хранения файлов (.svn в каждой папке или только в корне, files или sqlite бэкенд).
Правильно говорят в SVN — нет такой проблемы, так как svn субмодули хранятся в каждой директории. Поэтому можно сделать огромный репозиторий а работать только с частью. История тоже насколько я помню индексируется по субдиректориям.
В связи с этим совсем непонятно почему svn пытается отказаться от .svn в каждой папке, ведь это их ключевая фишка (хотя понятно что косяков было много).
Если бы git submodule могли работать по такому же сценарию! А так закомитил в сабмодуль, надо идти комитить parent module. Может кто знает как это сделать автоматически на сервере?
В связи с этим совсем непонятно почему svn пытается отказаться от .svn в каждой папке, ведь это их ключевая фишка (хотя понятно что косяков было много).
Если бы git submodule могли работать по такому же сценарию! А так закомитил в сабмодуль, надо идти комитить parent module. Может кто знает как это сделать автоматически на сервере?
Мне думается 4 ляма коммитов в реальном workflow не потребуется, оно может быть важно как история на всякий случай.
По этому мне видится такая картина — держать рабочую копию с последними 10ю тысячами коммитов, и периодически синхронизировать с полным репозиторием.
При слонировании репозитория гиту можно указать глубину, которую необходимо забирать.
А вообще да, интересно было бы посмотреть другие системы контроля версий в сравнении.
По этому мне видится такая картина — держать рабочую копию с последними 10ю тысячами коммитов, и периодически синхронизировать с полным репозиторием.
При слонировании репозитория гиту можно указать глубину, которую необходимо забирать.
А вообще да, интересно было бы посмотреть другие системы контроля версий в сравнении.
А если какая-то часть не менялась на протяжении 10000, ядро, например. В общем без знания самих проектов и истории — это все спекуляции.
Почему они не могут разделить не совсем понятно — не держат же они 1.5 млн файлов в одной папке. Тот же Android использует open source 'repo' и вроде все работает.
Почему они не могут разделить не совсем понятно — не держат же они 1.5 млн файлов в одной папке. Тот же Android использует open source 'repo' и вроде все работает.
Вероятно имеет смысл сделать настройку, сколько коммитов и/или незакрытых/несмерженных веток и/или возраст последнего коммита хранить в рабочем репе, а всё остальное пушить на полный, если его там ещё нет.
Каждый коммит содержит мгновенное состояние всего подконтрольного проекта.
Дифы высчитываются как разница этих состояний.
Поэтому ваши опасения напрасны.
Дифы высчитываются как разница этих состояний.
Поэтому ваши опасения напрасны.
Я дико извиняюсь за флейм, но термин "слонирование репозитория" мне дико доставил ;-)
Понимаю, что опечатка, но в контексте топика уж крайне жизненная.
Все-таки надеюсь никогда не увидеть таких объемов. Хотя время покажет. Как всегда.
Понимаю, что опечатка, но в контексте топика уж крайне жизненная.
Все-таки надеюсь никогда не увидеть таких объемов. Хотя время покажет. Как всегда.
Не указано самое интересное: какую систему контроля версий они используют сейчас, что у них нет проблем с таким большим репозиторием?
Я думаю GIT нужно (если ещё это не прописано) опираясь на этот тест прописать в своих доках рекомендации на к-во комитов и т.д. А то получается — извините но я засунул в стиралку 3 шубы и она поломалась
4 млн коммитов, линейная история и около 1,3 млн файлов. Размер папки .git — около 15 ГБ
Опыт намекает, что если у ребят будет не тестовый один репозиторий такого размера — то медленная работа с ним git будет наименьшей их проблеммой :).
ИМХО, высосанный из пальца тест -_-.
Давайте говорить прямо, на производительность, потребление ресурсов и оптимизацию разработчики Open Source как правило забивают. Достаточно взять любую графическую среду linux например.
Заметьте, в противоположность им, разработчики коммерческих компаний (нормальные разработчики из Гугл/фейсбук, а не индусы-аутсорсеры), наоборот, такими проблемами обеспокоены. Видимо, они более ответственные люди и лучше разбираются в данной области.
Вывод, если вы хотите получить качественный продукт, не пользуйтесь бесплатным ПО! Лучше закажите его разработку у профессиональных разработчиков! (подозреваю, в этом комменте не хватает только номера телефона ответственных разработчиков)
Заметьте, в противоположность им, разработчики коммерческих компаний (нормальные разработчики из Гугл/фейсбук, а не индусы-аутсорсеры), наоборот, такими проблемами обеспокоены. Видимо, они более ответственные люди и лучше разбираются в данной области.
Вывод, если вы хотите получить качественный продукт, не пользуйтесь бесплатным ПО! Лучше закажите его разработку у профессиональных разработчиков! (подозреваю, в этом комменте не хватает только номера телефона ответственных разработчиков)
Мне выглядит проблема немного надуманой.
Для такого большого репозитория любая комерческая система будет давать результаты даже хуже. Постотрите 5-летней давности статьи от гугла Perforce. Perforce на 1,5 ТБ репозитарии з 10-15 годами истории просто при отдаче статуса загрузил любое железо и результат будете ждать к вашей пенсии. Потому и апрещают и ограничивают подобные запросы
Возьмём любую комерческую систему, а перепробовал я их много на подобном размере AccuRev, ClearCase, Perforce, Subversion, CVS и получение статуса рабочей копии у вас займёт вечьность при подобной архитектуре. Фейсбук всё ещё носится со своей монолитной архитектурой, хотя уже давно было ясно что для их размеров она не подходит абсолютно. Решение здесь только одно разделяй и властвуй. Нужны подрепозитарии и конкретная версия собирается из зависимостей на конкретные версии зависимых версий. Это как раз то что называется Essence of Configuration Management и то что системы подобные ClearCase, AccuRev декларируют как решённую задачу.
А кросзависимости проєктов, так на мой взгляд это большой арзитектурный косяк, ручаюсь они уже сейчас имеют из-за этого большие проблемы.
Думаю Цукерберг должен издать манифест подобный Безовскому. Все системы должны взаимодействовать между собой ИСКЛЮЧИТЕЛЬНО через документированые и версионированые интерфейсы(что это будет IPC, SharedMemory, HTTP REST, SOAP отдаётся на откуп разработчикам) кто не следует этому правилу будет уволен.
Для такого большого репозитория любая комерческая система будет давать результаты даже хуже. Постотрите 5-летней давности статьи от гугла Perforce. Perforce на 1,5 ТБ репозитарии з 10-15 годами истории просто при отдаче статуса загрузил любое железо и результат будете ждать к вашей пенсии. Потому и апрещают и ограничивают подобные запросы
Возьмём любую комерческую систему, а перепробовал я их много на подобном размере AccuRev, ClearCase, Perforce, Subversion, CVS и получение статуса рабочей копии у вас займёт вечьность при подобной архитектуре. Фейсбук всё ещё носится со своей монолитной архитектурой, хотя уже давно было ясно что для их размеров она не подходит абсолютно. Решение здесь только одно разделяй и властвуй. Нужны подрепозитарии и конкретная версия собирается из зависимостей на конкретные версии зависимых версий. Это как раз то что называется Essence of Configuration Management и то что системы подобные ClearCase, AccuRev декларируют как решённую задачу.
А кросзависимости проєктов, так на мой взгляд это большой арзитектурный косяк, ручаюсь они уже сейчас имеют из-за этого большие проблемы.
Думаю Цукерберг должен издать манифест подобный Безовскому. Все системы должны взаимодействовать между собой ИСКЛЮЧИТЕЛЬНО через документированые и версионированые интерфейсы(что это будет IPC, SharedMemory, HTTP REST, SOAP отдаётся на откуп разработчикам) кто не следует этому правилу будет уволен.
Мне выглядит проблема немного надуманой.
Для такого большого репозитория любая комерческая система будет давать результаты даже хуже. Посмотрите 5-летней давности статьи от гугла о оптимизации Perforce. Perforce на 1,5 ТБ репозитарии з 10-15 годами истории просто при отдаче статуса загрузит любое железо и результат будете ждать к вашей пенсии. Потому запрещают и ограничивают подобные запросы вообще как клас.
Возьмём любую комерческую систему, а перепробовал я их много на подобном размере AccuRev, ClearCase, Perforce, Subversion, CVS и получение статуса рабочей копии у вас займёт вечность при подобной архитектуре. Фейсбук всё ещё носится со своей монолитной архитектурой, хотя уже давно было ясно что для их размеров она не подходит абсолютно. Решение здесь только одно «разделяй и властвуй». Нужны подрепозитарии и конкретная версия собирается из зависимостей на конкретные версии зависимых версий. Это как раз то что называется Essence of Configuration Management и то что системы подобные ClearCase, AccuRev декларируют как решённую задачу(другой вопрос как они это решили и что несмотря на красивую архитектуру на бумаге, реализация такая что хочется подвергнуть разработчиков медленной пытке).
А кросзависимости проэктов, так на мой взгляд это большой арзитектурный косяк, ручаюсь они уже сейчас имеют из-за этого большие проблемы.
На мой взгляд Цукерберг должен издать манифест подобный тому что издал Безос в своё время. Все системы должны взаимодействовать между собой ИСКЛЮЧИТЕЛЬНО через документированые и версионированые интерфейсы(что это будет IPC, SharedMemory, HTTP REST, SOAP отдаётся на откуп разработчикам) кто не следует этому правилу будет уволен.
Для такого большого репозитория любая комерческая система будет давать результаты даже хуже. Посмотрите 5-летней давности статьи от гугла о оптимизации Perforce. Perforce на 1,5 ТБ репозитарии з 10-15 годами истории просто при отдаче статуса загрузит любое железо и результат будете ждать к вашей пенсии. Потому запрещают и ограничивают подобные запросы вообще как клас.
Возьмём любую комерческую систему, а перепробовал я их много на подобном размере AccuRev, ClearCase, Perforce, Subversion, CVS и получение статуса рабочей копии у вас займёт вечность при подобной архитектуре. Фейсбук всё ещё носится со своей монолитной архитектурой, хотя уже давно было ясно что для их размеров она не подходит абсолютно. Решение здесь только одно «разделяй и властвуй». Нужны подрепозитарии и конкретная версия собирается из зависимостей на конкретные версии зависимых версий. Это как раз то что называется Essence of Configuration Management и то что системы подобные ClearCase, AccuRev декларируют как решённую задачу(другой вопрос как они это решили и что несмотря на красивую архитектуру на бумаге, реализация такая что хочется подвергнуть разработчиков медленной пытке).
А кросзависимости проэктов, так на мой взгляд это большой арзитектурный косяк, ручаюсь они уже сейчас имеют из-за этого большие проблемы.
На мой взгляд Цукерберг должен издать манифест подобный тому что издал Безос в своё время. Все системы должны взаимодействовать между собой ИСКЛЮЧИТЕЛЬНО через документированые и версионированые интерфейсы(что это будет IPC, SharedMemory, HTTP REST, SOAP отдаётся на откуп разработчикам) кто не следует этому правилу будет уволен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы с производительностью Git на большом репозитории