Google — это 2 миллиарда строчек кода

[@joann]

Думаю там не тока сам pagerank а все алгоритмы ранжирования, за которые сеошники большие денги дали бы

[@Yoschi]

У конкурента вполне может быть датацентр-другой.

[@RPG]

На примере Хромиума: каталог third_party содержит несколько гигабайт кода (это его состояние несколько 6 лет назад, сейчас там творится просто кошмар), надёрганного их OpenSource проектов, что превышает объём кода самого Хромиума. С такими методами разработки проект растёт очень быстро.

[@orcy]

Судя по видео там кроме исходного кода еще и конфигурация, документация, код который генерируется, итд. Из 40к коммитов ежедневно, только 15к это человек, остальное это роботы. Так что сказать «работа программистов Google выглядит фантастической» вряд ли можно по количеству исходного кода у этом репозитории.

[@Duche3d]

«Google используется собственная VCS, которая называется Piper» — хм… странно я думал она должна называться Pied Piper :)

[@AxisPod]

Только вот проблема в том, что счастье не в строчках. И для кода так или иначе нужные иные метрики.

Разговор о большом кол-ве строк для меня является наоборот отрицательным показателем.

[@Rasifiel]

Чем не нравятся метрики по количеству строчек не в обсуждении продуктивности разработчиков, а в обсуждении эффективности VCS?

[@leonid-lapidus]

не модная среди разработчиков git, а Mercurial

Разбирающиеся в теме, поясните, пожалуйста, разницу. Я был убеждён, что это почти одно и то же.

[@Rasifiel]

У них общее только то, что и то, и то DVCS

[@Athari]

Mercurial — это примерно как Git, только нормальный и непопулярный.

[@leonid-lapidus]

Александр, можете чуть подробнее про «нормальный». В git-е есть вещи, которые мне не нравятся. Может быть Меркуриал для меня.

[@Rasifiel]

Меркуриал гораздо более «классический». Во всяком случае переход на него с свна был совершенно безболезненный — к классическим концепциям добавляется слой обеспечивающий собственно букву D. Классические бранчи (но без свновых недостатков) особенно радовали. Git для меня был болезнен и требовал постоянно дергать документацию и искать как что-то сделать.

[@Metus]

На работе используем mercurial.
Возможно я ошибаюсь, но без плагинов нет чего-то вроде rebase и прочего.
Нет разделения веток на локальные и внешние — есть просто ветки. pull и push затягивает и толкает все ветки разом.
Более того, ветка именно ветка, она выходит из одной, она существует отдельно от других, её можно смержить с другой.
Не знаю, нормально это или нет?

[@Rasifiel]

Странно, что все обсуждают размер репозитория, а не концепцию «один репозиторий для всего»

[@Rasifiel]

Ну там много чего можно добиться только с ресурсами порядка Гугла. Куча собственной самописной инфраструктуры и своих решений. Если Гугл с ФБ сделают коробочное решение для решения таких проблем, то будет хорошо.

[@batyrmastyr]

Странно говорить что репозиторий один, если для его работы гробятся ресурсы 10 ЦОДов. Сдаётся мне речь не об аналоге git-репозитория речь идёт, а об одном логическом хранилище из которого делают piper clone piper.google.TLD:/<конкретный репозиторий>.

[@Rasifiel]

Нет. Вы неправильно представляете)
google-engtools.blogspot.ch/2011/06/build-in-cloud-accessing-source-code.html
И откуда вы взяли, что «гробятся ресурсы 10 ЦОДов» только на хранилище кода?)

[@batyrmastyr]

Да, представлял неправильно. )
А про «только» — вроде как логично было предположить, что в гугле не кладут все яйца в одну корзину. Хотя вы правы — они столько ЦОДов развернули скорее для уменьшения задержек реакции внутренних сервисов, а не из-за большой прожорливости хранилища.

[@Rasifiel]

У Гугла и так куча ДЦ по всему миру и VCS в результате просто распределили по ним, чтобы иметь адекватную задержку и скорость работы с ним.

[@ArtRoman]

Возможно, по аналогии с репозиторием Андроида – там своя тулза управления репозиторием "repo", но внутри просто сотни обычных git-репозиториев (с разделением по устройствам, по приложениям, по компонентам системы, и те огромное количество тех самых third-party библиотек). Причём их метаданные (.git) отделены от реальных данных через символьные ссылки. При обновлении сначала обновляются метаданные, потом все изменения разом накатываются на файловую систему.
Тоже можно сказать, что весь код в одном репозитории, хотя на самом деле это не совсем так.

[@BelBES]

Мало того, весь этот «Google-код» находится в едином репозитории, которым ежедневно пользуются 25 000 сотрудников поискового гиганта.

Рейчел заметила, что такой принцип хранения исходников позволяет разработчикам Google "… чувствовать необычную свободу в использовании и комбинировании кода других проектов".

По её словам, Piper управляет 85 терабайтами данных «Google-кода», в который ежедневно 25 000 разработчиков делают примерно 40 000 коммитов. Таким образом за каждую неделю модифицируются 250 000 файлов и 15 миллионов строк кода.

Интересно, а среди сотрудников компании много героев, которые клонировали себе весь репозиторий, а не только рабочую ветку?)
Ну и бедные новобранцы, который с дуру решают скачать весь код)

[@Metus]

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

[@Rasifiel]

Там не надо ничего клонировать. Есть FUSE модуль который делает магию — подхватывает read only версию нужного файла, а при изменениях создает рабочую копию у пользователя. Собственно статья по теме: google-engtools.blogspot.ch/2011/06/build-in-cloud-accessing-source-code.html

[@biskovs]

2 миллиарда строчек? Брали пример с Маяковского? :)