Использование Mercurial в Facebook

Интересно, найдется ли самурай, который отважится так же разогнать git?

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

Неужели официальная система контроля версий ядра линукс действительно не готова для такого?

не. Её закапывать пора. Впрочем, как и ядро. Но проблема в том, что другого ядра у нас нет, и не предвидится, а вот ртуть — уже есть.

К сожалению для него не изобрели пока аналог tig'а

По сути, все изменения открыты

По сути, это типичные ынтерпрайзные патчи - нужные конкретному ынтерпрайзу, но мало применимые вне его:

«hgwatchman will disable itself if any of the following extensions are enabled: largefiles, inotify, eol; or if the repository has subrepos»

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

Пусть и так. Но ведь гит - это major player в мире систем контроля версий, стандарт де-факто, можно сказать. Особенно учитывая многомиллионную аудиторию гитхаба.

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

Пусть и так. Но ведь гит - это major player в мире систем контроля версий, стандарт де-факто, можно сказать. Особенно учитывая многомиллионную аудиторию гитхаба.

давай ещё вспомним аудиторию винфака...

Чувствую я, что в скором времени что-то такое и произойдет.

вряд-ли. Некоторые вещи(точнее многие) в mercurial'е если и есть, то только чудовищными костылями (типа удаления из истории). Потому-что они на самом деле не нужны. Но эту ненужность надо было осознать ДО проектирования DVCS. Не осознали... А вот при проектировании ртути это было УЖЕ известно, потому и архитектура получилась более продуманная и совершенная. Да, посмотри на велосипеды из 19го века, они тоже уродские. И тоже несовместимые.

так и запишем: недодевелоперы фейсбука ниасилили гит.

Можно для Ъ, чем оно лучше Magit?

Нет необходимости в погружении в удивительную по своей комбайновости вселенную емакса
!

Но ведь гит - это major player в мире систем контроля версий. Особенно учитывая многомиллионную аудиторию гитхаба.

Мимо. Свн - да. Учитывая то, что битбакет давно уже не гитоспецифичный, рано или поздно гитхабу тоже придётся поддержать что-то кроме гита.

Учитывая то, что битбакет давно уже не гитоспецифичный,

Что? У тебя как-то всё в обратную сторону работает.

Интересно, найдется ли самурай, который отважится так же разогнать git?

Пишут, что теперь hg у них местами в 5, а то и в 50 раз быстрее, чем git.

у них

Возникает вопрос, зачем разгонять гит, чтобы он быстро работал в facebook?

Возникает вопрос, зачем разгонять гит, чтобы он быстро работал в facebook?

Зачем facebook. Одноклассники же!

Свн - да

Свн своё уже отработал. Может у него и до сих пор весомая доля, но пользуются им в основном по инерции. Прошлый век, в современных реалиях не оч.

Но ведь гит - это major player в мире систем контроля версий, стандарт де-факто, можно сказать. Особенно учитывая многомиллионную аудиторию гитхаба.

В СПО только. Проблема FB это типичная проблема жирных контор, которые много лет сидят на VCS типа subversion и perfroce используя один реп как файловую помойку сразу для всех своих проектов практически без веток и всё делая в trunk'е. Они тупо не думают о проблеме масштабирования в ширь и, переходя на другие VCS, переносят с собой паттерн использования репа как файловой помойки. В мире СПО это антипаттерн и такого просто нигде нет.

В принципе, тому же гитхабу скинуться на пиво Торвальдсу и еще десятке матерых хакеров ничего не стоит, чтобы те сели и за неделю сочинили какой-нибудь там git reloaded с тем же пользовательским интерфейсом,

Матёрым хакерам нужен стимул поболее бутылки пива. Спасение утопающих в мире СПО обычно проблема самих утопающих. Нужно - бери и делай сам или готовь заманчивые $.

с тем же пользовательским интерфейсом, но более прямым дизайном,

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

hg у них местами в 5, а то и в 50 раз быстрее, чем git

Шах и мат, гитомакаки.

Шах и мат, гитомакаки.

Только в фантазиях рутефанов.

Проблема FB это типичная проблема жирных контор, которые много лет сидят на VCS типа subversion и perfroce используя один реп как файловую помойку сразу для всех своих проектов практически без веток и всё делая в trunk'е. Они тупо не думают о проблеме масштабирования в ширь и, переходя на другие VCS, переносят с собой паттерн использования репа как файловой помойки.

Оне просто лохе!

Стер жыр с монитора

After a couple months of monitoring and fixing discrepancies in usage, we got the rate low enough that we were comfortable enabling Watchman by default for our engineers.

rate low enough

Ню-ню.

используя один реп как файловую помойку сразу для всех своих проектов практически без веток и всё делая в trunk'е

О да, куда лучше иметь тысячу реп, отслеживать взаимные обратные совместимости их релизов, заодно и админам будет чем заняться - континиюус интегрейшон, вот это всё. А лучше связать репы сабмодулями, чтобы вообще никому не скучно было.

Достаточно для того, чтобы считать проведённое за этими занятиями время не бесполезно потраченым.

А разве недавно не было новости, что в том же пейсбуке используют гит (или даже перешли на него) и как-то нереально его ускорили и меркуриал сильно соснул? Или у них там социалистическое соревнование? :3

А разве недавно не было новости, что в том же пейсбуке используют гит (или даже перешли на него)

Как говориться, ссылку или GTFO. Насколько я могу судить по mercurial-devel@, Facebook довольно давно использует именно Mercurial, дает работу некоторым разработчикам, и хостит спринты.

Как такое може быть!!! Гит благодатен!!! Луниус угнети их!!! Все самые четки поцыки и тяночки пользуют гит остальные лалки азазазазаза!!!!!

http://habrahabr.ru/post/137615/

Вот оно что, понятно каким образом они решили проблему с производительностью гита :3 Остальное, наверное, работа моего воображения :3

http://habrahabr.ru/post/137615/

Это было 2 года назад, и упоминается только синтетический тест. Может, они хотели соскочить с Mercurial? %)

Шах и мат, гитомакаки.

ты зачем сбрил усы дурик?

А лучше связать репы сабмодулями, чтобы вообще никому не скучно было.

ты не осилил git submodule ?

А разве недавно не было новости, что в том же пейсбуке используют гит (или даже перешли на него) и как-то нереально его ускорили и меркуриал сильно соснул?

около года назад что-то подобное было

ты не осилил git submodule ?

Это же уже не модно.

2014
грезить о боеспособности сабмодулей

грезить о боеспособности сабмодулей

че? оно просто работает

Watchman exists to watch files and record when they actually change. It can also trigger actions (such as rebuilding assets) when matching files change.

битбакет давно уже не гитоспецифичный

есличо, битбакет изначально только hg и умел. Поддержка git была добавлена позже.

О да, куда лучше иметь тысячу реп, отслеживать взаимные обратные совместимости их релизов, заодно и админам будет чем заняться - континиюус интегрейшон, вот это всё. А лучше связать репы сабмодулями, чтобы вообще никому не скучно было.

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

И старая русская забава «никто не коммитит в транк, я сейчас мёржить буду»

Без гита он конечно очень популярный был.

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

Ну и что? 3-4 человека в команде из тысяч, занимающиеся допиливанием VCS. Big fucking deal.

Ну идеи у них весьма очевидные - ничего нового они на самом деле не придумали:

• Мониторить файловую систему чтобы знать что изменилось в рабочей копии без её полного сканирования
• sparse апдейты, при которых выкачиваются только метаданные (в терминоголии git commit и tree объекты, но не blob'ы)

Прежде всего надо сказать что необходимость в этом возникает только по причине кривой организации работы: svn-like «одна большая помойка», в то время как проект должен быть разбит на отдельные небольшие репы. Звиняйте, но если всё валится в одну большую кучу, рано или поздно потребуются какие-то костыли чтобы это поддерживать.

Первая идея в общем здравая, однако не надо забывать что status на всё дерево - довольно глупая операция, а status на ту часть с которой вы работаете выполняется быстро. В git это «git status» vs. «git status .» (или поддиректория), не знаю умеет ли hg аналог второго. Во-вторых, файловая система с вменяемой политикой кэширования метаданных убирает необходимость в этой фиче (ZFS ARC, например, замечательно справляется). Ну если вдруг трындец надо на холодном кэше сделать status на всё дерево - то вопросов нет, фейсбуковская поделка отдаст состояние мгновенно.

А вот вторая идея кроме того что в голос орёт о необходимости нормально организовать репозиторий, мало применима в реальных условиях, ибо во-первых требует неслабой инфраструктуры для поддержки (модифицированный сервер + мемкэши), во-вторых, делает из dvcs по сути централизованную систему с единой точкой отказа и невозможностью работать offline. Глупо говорить о 10x увеличении скорости pull, когда log --patch превращается в тыкву.

Итого, тех же феноменальных ускорений на больших деревьях можно добиться

• запуская долгие команды только на том поддереве, на котором они реально нужны
• и добавив git fetch в cron чтобы не ждать скачки обновлений (тогда pull станет ещё на несколько порядков быстрее фейсбуковского поскольку почти не будет требовать сетевого общения, с сохранением полной возможности работы offline)

Ну и, ещё раз, нормальная огранизация репозитория - наше всё.

Никто не сравнивал git vs mercurial на 5..10 млн. мелких файлах по ~10 тыс. в каталоге?

а надо?

Угу. Есть у меня задумки :)

Не могу представить себе столь грандиозный проект, как 5...10 млн. мелких файлов, да ещё по ~10 тыс. в каталоге.

У NetBeans число файлов .java в текущей ревизии:

% find ./netbeans/main -type f -name "*.java" | wc -l
   44205

Размер локального Mercurial-репозитория NetBeans:

% du -d0 -h ./netbeans/main/
3,5G	./netbeans/main/