Previous Entry Share Next Entry
2016-01

Про контроль версий

... а точнее, про монолитные репозитории vs много репозиториев

http://gregoryszorc.com/blog/2014/09/09/on-monolithic-repositories/ - вот всё так.

TLDR: Люди уходят, приходят, проекты мержаются, мэпить это на топологию репозиториев - лишняя работа. Ну и операции часто должны (транзакционно) покрывать много репозиториев сразу.

Всё упирается только в контроль доступа к части репозитория (поэтому я сам по факту сейчас использую модель с многими репозами, увы), и в частичное клонирование. Это решаемо.

В итоге Google сидит на Perforce, а Facebook активно допиливает Mercurial, по мере того, как находят в нём новые ограничения :)

Ну и Git, кстати, начал шустро подтягиваться, когда фанаты увидели, что Hg стараниями фейсбука начал выходить из статуса маргинальной DVCS :)

This entry was originally posted at http://wizzard.dreamwidth.org/428016.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
develop7 April 6th, 2015
Git, кстати, начал шустро подтягиваться
не замечал. в чём это выражается?
когда фанаты увидели, что Hg стараниями фейсбука начал выходить из статуса маргинальной DVCS :)
fanboy-driven development ;)

soloviewoff April 6th, 2015
Facebook на Меркуриал уже вроде как ну вот почти пересел. Интересный talk по теме, если не видел - https://developers.facebooklive.com/videos/561/big-code-developer-infrastructure-at-facebook-s-scale

soloviewoff April 6th, 2015
Еще: а есть подробности про то, что Git начал шевелиться?

kurilka April 6th, 2015
+1 тоже интересно о чём речь

wizzard0 April 6th, 2015
ну э см ниже

max630 April 6th, 2015
Какой-то суперновой фичи которую можно было бы вставить в рамочку нет.

Для клона есть shallow clone, доведённая до ума к 1.9.0, и alternates, которая была всегда. Мне кажется, это закрывает все потребности.

Для чекаута есть sparse checkouts, есть флаг assume-unchanged, который должен помочь для inotify-based решений. Сейчас в разработке какой-то патч на "untracked cache", но я не слежу особо. Как я понял, не так просто получить заметный прирост скорости.

Ещё они постоянно пилят алгоритмы упаковки, но это совсем непонятно для большинства, для меня по крайней мере.

Прорывом сейчас может быть быть narrow clone только, но его никто не делает.


slonopotamus April 6th, 2015
Я вам как бывший обладатель репозитория на 1.5TB истории и 1M файлов в working copy скажу: working copy достаточно быстра. На сраном Core 2 Quad при горячем дисковом кэше (около полгига оперативки) git status занимает вполне приемлемые 2с. А вот всякие git blame, git gc - ад пиздеца. Blame утыкается в I/O, а gc выжирает тонны оперативки, еле влезая в 8GB RAM, даже при windowMemory=512M и одном потоке gc. Ну и выполняется этот gc около суток. А, еще как-то ребейзил один коммит на трехнедельную историю (в отпуске был). Заняло это безобразие около часа, в основном пожирание проца.

max630 April 6th, 2015
> 1.5TB истории, 1M файлов в working copy

Это довольно экстремально звучит, да

> ребейзил один коммит ... около часа

Вот на этот предмет я бы попробовал новые версии, возможно они это улучшили. А вообще странно звучит. Я правильно понял что именно 1 коммит перенести в другое место?

slonopotamus April 6th, 2015
Да, ребейз одного небольшого коммита (ну строчек на 200 diff'а) вперед по истории через ~2k ревизий. Разбирательства показали, что проблема была в git rev-list --ignore-if-in-upstream, но дальше особо никуда не продвинулось: http://git.661346.n2.nabble.com/VERY-slow-git-format-patch-tens-on-minutes-during-rebase-and-rev-list-during-rebase-i-td5286226.html

max630 April 7th, 2015
да, не очень. Причём даже не сказать что это сам rebase виноват, насколько я вижу все эти функции для подсчёта эквивалентных патчей особо не оптимизировали.

Сейчас cherry-pick можно указывать диапазон и --abort, --continue, всё вот это вот. Так что для простых случаев можно без rebase обойтись.

mbr April 6th, 2015
Я сильно ленив, чтобы освоить весь текст на английском, в чем суть?

Лично я поступаю следующим образом - во время разработки пользуюсь множеством репозиториев, к сдаче проекта форкаю все в один.

Anatoly Borodin April 6th, 2015
Репозиториев, или бренчей?

mbr April 6th, 2015
Написано ровно то, что подразумевалось. В чем суть вопросов?

shabunc April 6th, 2015
я полагаю, человек удивился.
наверное, суть вопросов в том, что если репозиторий весит 40 гигов то под каждую фичу особо не покопируешься.

так же не совсем понятно что подразумевается под "форком всего в один"

mbr April 7th, 2015
40 гигов? Урежьте сома - в ведре 1.5.

shabunc April 7th, 2015
ну, во-первых это не всегда возможно, во-вторых я работаю в бранчах и не могу придумать ни одного плюса от работы с N копиями одного и того же репозитория.

shabunc April 7th, 2015
ой, вру, один есть плюс - это когда что-нибудь типа плюсового проекта и ребилд всего занимает десятки минут.

Anatoly Borodin April 6th, 2015
И "форкать в один" нельзя, это противоположная по смыслу операция. Речь идёт о мердже (слиянии)?

nponeccop April 6th, 2015
Я так понимаю, речь о форке проекта, потому что получается две кодобазы (во многих репозах и в одном).

На уровне DVCS это может быть вообще не слияние, а создание нового репоза с 1 комммитом.

wizzard0 April 6th, 2015
сделать форк, внутри которого слитые репозы

mbr April 7th, 2015
Ага. Неужто так непонятно изъясняюсь?

max630 April 7th, 2015
Надо сказать, что представление об одном централизованном репозитории в котором лежит всё история компании за 20 лет - оно тоже довольно идеализированно. Если компания жила вообще без системы контоля версий, потом лесколько лет vss, потом ещё несколько лет на каком-то cvsподобное говно, которое не умеет в удалённые файлы - в итоге у неё конечно есть монолитный репозиторий, но то что там лежит назвать историей можно с большой натяжкой.

Так что если не париться и копировать директории с из репы в репу - то будет как минимум не хуже. А если ещё не забывать писать что откуда скопировано - то и вообще замечательно.

unknown_orient April 7th, 2015
Гугл вроде как давно от перфорса отказался.

sorcerer_ April 8th, 2015
У меня есть подозрения, что автор вообще не понимает проблемы.
Так же у меня есть подозрения, что кодобаза какого нибудь свежего Отсосин Крида раз в 5 больше всего кода, когда-либо написанного Фейсбуком.

vgrichina April 8th, 2015
> Так же у меня есть подозрения, что кодобаза какого нибудь свежего Отсосин Крида раз в 5 больше всего кода, когда-либо написанного Фейсбуком.

3д движки не такие уж большие вообще-то. Особо сравнимо с херовой тучей галимой бизнес логики и хаков в которую обычно превращается любой достаточно старый и популярный веб-сервис. Это еще не считая то что 1) там очень много экспериментов и итераций vs игрушка которую разрабатывают один раз и забывают 2) куча инфраструктурной хрени включая форки open-source проектов и собственные БД и даже компилятор.

sorcerer_ April 9th, 2015
> 3д движки не такие уж большие вообще-то.

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

vgrichina April 9th, 2015
А, ну если ресурсы в контроле версий, то это все немного другая категория. DVCS к этому вообще не готовы пока что.

vgrichina April 8th, 2015
Самое время вспомнить закон Конвея – https://en.wikipedia.org/wiki/Conway's_law

Нет никаких причин предполагать что он не распространяется на системы контроля версия. Так что палево, Google и Facebook – большие монолитные конторы ;)

Монолитный репозиторий Гугла

bik_top April 9th, 2015
> а точнее, про монолитные репозитории vs много репозиториев
> В итоге Google сидит на Perforce

А есть какие-то дополнительные ссылки на предмет факт-чекинга? Автор упомянутой статьи ссылается на пдфку 2011 года на сайте Перфорса, где они публикуют саксес-стори, внезапно, Перфорса.

Выглядит как притягивание за уши просеянных пруфов под заранее сформированную точку зрения.

За последнюю неделю сталкивался с двумя маленькими репозитриями Гугла на Гитхабе — Unity-плагины для рекламы и облачного хранения сейвгемов.

Про Фейсбук не знаю, но тоже недавно скачивал их популярную плюсовую библиотеку Folly с Гитхаба.

Edited at 2015-04-09 11:50 am (UTC)

Re: Монолитный репозиторий Гугла

surmenok April 9th, 2015
Гугл последнее время стал активно пользовать гитхаб, у них больше сотни репозиториев: https://github.com/google
Вот здесь в 2011 году писали что внутри они пользуют Perforce: http://www.quora.com/What-version-control-system-does-Google-use-and-why

  • 1
?

Log in

No account? Create an account