В Launchpad добавлена поддержка git-репозиториев

Две репы, одна 14Gb, вторая — 71Gb. Всё работает быстро. ЧЯДНТ?

Детские размеры. Один репозиторий 1.5TB, gc и blame тормозят адово. GC еще и оперативку жрет тоннами (в пике 10+ GB RAM при одном потоке gc и windowMemory=512M).

Поделитесь с общественностью, чем наполнен этот git реп, неужели исходники неизвестного нечто?

Не вижу проблем делать это с гитовыми тегами.

Эмм... В bazaar отдельной ветке физически соответствует отдельный каталог.

Не очень хорошая идея

задолбались, когда переводили ВСЕ исходники в единый репозиторий

Ну так ССЗБ.

git на эту роль не годится, так как фактически не умеет работать с блобами и гигантскими репозиториями в десятки гигабайт

А кто умеет? У меня самый толстый гитовый репозиторий - ядро и работа с ним идёт с вполне терпимой производительностью.

Эта, а зачем делать настолько толстый реп? вы там порно штоле храните?

svn

Репы крупных компаний, типа упомянутого выше facebook, могут занимать десятки и сотни гигабайт.

Поделитесь с общественностью, чем наполнен этот git реп, неужели исходники неизвестного нечто?

Онлайн 3D игра, около семи лет разработки в среднем командой из 50 человек. Причем исходники арта (psd, maya, звук) в этот объем не входят, с ними отдельная жесть. Оно вообще живет на svn'е, я себе через git-svn делал клон.

Когда на позапрошлой работе я и шефом отлаживали и дописывали проект заказчику у него уже на месте в условиях отсутствия сети - обмен изменениями между собой с использованием SVN был больше похож на секс в скафандре, ластах и противогазе - вроде и можно но крайне неудобно. Патчи через флешки, а потом я просто вынес нахрен свою рабочую копию, попутно потеряв пару изменений.

С тех пор я не то что бы фанатичный поклонник DVCS, но использовать предпочитаю их.

В виденом мной большинстве случаев такие репы состоят из «все исходники что есть мы запихаем в одну репу».

Другое дело, что у гита submodules - настолько сырые, что их использовать очень неудобно.

Все исходники в одной репе? не тогда удивляться особо нечему.

Внезапно, в svn можно сделать копию репозитория.

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

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

Ты так говоришь будто это что-то плохое

Но и особо хорошего на мой взгляд немного.

Ты лучше скажи как в случае разных реп связывать изменения одного отдела с изменениями другого отдела?

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

В Teamcity используется тот же скриптик, только с учётом реалий ТС. Получилось вполне удобоваримо, но это моя невысокая колокольня и мне держать всё в одном ещё хуже получается.

А если отделов over9000?

тут не знаю, нет опыта в овер9к отделов

Один реп это сквозная нумерация ревизий и огромные возможности по автоматическому тестированию и интеграции различных изменений от различных групп.

см. выше. плюс сквозные изменения от овер9к отделов - ИМХО не самая удачная идея.

Ну а если вышеперечисленное «ниалё» и svn подходит - значит svn. В конце-концов под задачу инструмент выбирается.

В итоге есть сборочный скриптик строк на полсотни, который вытаскивает последнюю ревизию, делает сборку, в фаил который уходит в результат билда пишет конкретную ревизию каждой репы.

Это работает когда проект один. В репозитории могут жить 100500 проектов, которые завязаны друг на друга и у каждого свой релиз-цикл.

Ну а если вышеперечисленное «ниалё» и svn подходит - значит svn. В конце-концов под задачу инструмент выбирается.

svn тут тоже не идеал, так как не решает локальных проблем разработчика. Разработчик не будет выкачивать 100 гигов. Я встречал когда поверх svn добавляют свои велосипеды, чтобы можно было удобно в git-style работать с частью этого хаоса на локалхосте :)

Это работает когда проект один. В репозитории могут жить 100500 проектов, которые завязаны друг на друга и у каждого свой релиз-цикл.

Когда в репе живут 100500 проектов, то код и история коммитов имеют тенденцию превращаться в кашу, особенно если разработчики не слишком парятся на предмет атомизации коммитов(или как это правильно назвать) и имеют склонность в одном коммите трогать сразу несколько связанных вещей. blame сразу превращается в увлекательную процедуру.

Если у связанных проектов есть свои релиз-циклы, а не всё выкатывается одним «тегом», то держать одну репу на всех тем более трэш, ибо кто-то стабилизируется, кто-то пилит новые фичи, кто-то ловит баги и норовит обвинить во всех смертных грехах тех кто фичи пилит, мол они всё сломали.

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

и имеют склонность в одном коммите трогать сразу несколько связанных вещей.

На это есть review

ибо кто-то стабилизируется, кто-то пилит новые фичи, кто-то ловит баги и норовит обвинить во всех смертных грехах тех кто фичи пилит, мол они всё сломали.

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

На это есть review

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

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

Автоматические тесты ловят таки не всё. Хотя и помогают, да.

Я скорее про ситуацию, когда на новом цикле разработки чистится deprecated и выкатывается что-то новое.

Может где-то и есть нормальный ревью,

В крупных компаниях оно есть.

Я скорее про ситуацию, когда на новом цикле разработки чистится deprecated и выкатывается что-то новое.

Это замечательно отлавливается тестами. Если ты почистил deprecated, а в каком-то отделе на него завязаны, то упадут тесты и твой коммит не попадет в репозиторий.

В крупных компаниях оно есть.

Я сейчас работаю на крупную американскую компанию, и никакого ревью у нас фактически нет.