Как стать автором
Обновить

Комментарии 64

В общем, разработчики из Facebook намекают на то, что хорошо бы переписать Git для улучшения производительности. Разделить репозиторий на несколько частей
они отказываются
.
Особенно доставило.
Как буд-то git и компания им чего-то должны.
Ну вот пусть и перепишут)
(Facebook перепишут)
Так ведь и перепишут, и выложат в паблик. Facebook активно поддерживает OpenSource. HipHop например для php написали.
Так и респект им! Кстати, за HipHop им отдельное спасибо.
Они то перепишут, но на PHP…
И будет работать быстрее… trollface
Можно подумать, что Facebook на одном PHP написан.
А что, на двух!?
Действительно найдется мало постов, где не будут троллить по поводу php.
Это очень хорошо, когда даже в связи с возникшими проблемами крупная компания продолжает поддерживать open-source разработки
Особенно доставило, что вы делаете выводы по пересказу письма.

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

Одно должно радовать простых пользователей — для Git эта история должна закончится положительно, и он будет модифицирован в лучшую сторону. Даже если это не произойдёт с его основной веткой, то скорее всего будет Fork…
Проблема есть (хотя большинства пользователей она не коснется) и ее надо решать. Но сама постановка вопроса удивляет.
Последний абзац этого текста — авторская отсебятина. Не нужно приписывать её людям из Facebook.
> Ни чего не скажешь, норм так ребята git хотят припахать…
О каких нормах идет речь?
НЛО прилетело и опубликовало эту надпись здесь
Ну сам фейсбук может и не скоро подобрался бы, но само по себе исследование полезное. Вот у нас, например, в SCM уже более 4.2 млн транзакций. И нам теперь не нужно проводить собственное исследование, чтобы понять, что Git нам не подходит.
А что у вас за SCM, если не секрет?
Вы нифига не поняли из написанного. Или специально несёте ахинею.

Речь шла об исключительно синтетических тестах.
не совсем понятно, зачем хранить коммиты 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 ляма коммитов.
Он бы почитал, как устроена работа в ядре линукса. Там коммитеров, еще больше чем в какабуке, и никто такой дури не писал.
Видимо, этот дядька, зазнался, находясь в какабуке и решил с вершины своей чето крикнуть.
видимо они ветки мержат полностью, а не одним коммитом. С одной стороны в этом есть определённый резон, с другой, да, ССЗБ.
Опять попался. Написал коммент в топик от Ализара.
Ализар, хватит желтуху писать в хабр. Ценности никакой, кроме флуда для народа.
Не такая уж и желтуха. При работе с деревом ядра на не слишком мощной машине ощущаются неплохие тормоза.
Алексей, спасибо за комментарий. Ваше мнение очень важно для нас!
Проблемы с производительностью есть и на гораздо меньших репозиториях, git status в полминуты на холодном — напрягает.
Вот бы они производительность других систем проверили.
Интересно, а кто-нибудь подобные тесты для SVN проводил? Что там будет?
Скрипт для создания тестового репозитария запущен, через пару столетий можно будет протестить.
И еще бы про hg
Тоже было бы интересно почитать. Когда нас сподвигали перевести основные проекты с svn на git, нам пели интересные песни о том, как всё станет быстрее и лучше, особенно на операциях типа статус и прочих синхронизациях с репозиториями («ведь репы локальные!»). Увы, не стало почему-то. Что-то стало лучше и удобнее, что-то доставляет неудобства, но скорости не очень заметно. Может, мы чего-то не то делаем?
Винда?
Винда?
Догадка неверна, винды на рабочих станциях у нас нет ни одной. У меня линуксы. Федора, арч. А что не так с виндой в этом плане? Ну и нет чтобы посоветовать чего, сразу запинали :(
Под виндой очень сильно тормозит беганье по дереву директорий.
Если у вас есть конкретный вопрос — то попрошу полный вывод всего перечисленного:
    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 формата 1.6 говорите? В 1.7 используется одна дирректория для метаинформации
Я и говорю про разницу 1.6 и 1.7. Раньше иметь миллион файлов в svn репозитории было нормально, если ты работаешь в какой-то сабдиректории. А теперь в 1.7 точно так же как в .git или хуже?
Мне думается 4 ляма коммитов в реальном workflow не потребуется, оно может быть важно как история на всякий случай.

По этому мне видится такая картина — держать рабочую копию с последними 10ю тысячами коммитов, и периодически синхронизировать с полным репозиторием.

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

А вообще да, интересно было бы посмотреть другие системы контроля версий в сравнении.
А если какая-то часть не менялась на протяжении 10000, ядро, например. В общем без знания самих проектов и истории — это все спекуляции.
Почему они не могут разделить не совсем понятно — не держат же они 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 отдаётся на откуп разработчикам) кто не следует этому правилу будет уволен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории