Максим Олейник Partizan

А про добавление колонок на больших таблицах — здесь хорошо описано:
Опыт 1440 миграций баз данных — habr.com/company/wrike/blog/414441
Колонка добавляется как nullable ну и дальше аккуратно заполняется.

Обычно делаем CREATE INDEX CONCURRENTLY — PG создает индекс без блокировки таблицы в реалтайме. Ну и медленнее он работает конечно.

Интересно, сможете показать исходники export?

А как вы это делаете?

Да, подходящий кейс

Когда проекту больше 5 лет и миграций за тысячу — как-то по другому надо

ORM в миграциях нужна не столько для «удобства», сколько для потенциальной возможности смены СУБД

В миграциях этого точно не нужно — они одноразовые.

Транзакции в DDL

НЕ все базы поддерживают транзакции на уровне запросов по изменению структуры БД.
Долго работал и мучался с MySQL, у которой этого не было. Как там сейчас уже не в теме.

А много не надо. Человек 4-6 за один раунд, а потом анализировать, пилить, и снова тестировать.

Репо приватный. Выложил сценарий в gist: https://gist.github.com/715534

Естественно надо подбирать целевую аудиторию. Но это, конечно, может быть не просто, если ваша аудитория топ-менеджеры, например. Но всегда можно что-то придумать.

На сценарии? Я не давал ссылку на сценарии? В посте я только опубликовал один кейс для примера. Или я что-то не понял?

Вот именно, что впечатления. Жду полноценный обзор :)

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

Я бы еще добавил неудобство работы с субмодулями, у которых тоже есть субмодули со своими субмодулями.

Git-way: один модуль — один репозиторий. Можно конечно объедить группу репозиториев в суперрепозиторий, но обновляться будет не совсем удобно. Не пробовал.
Или положите все в один репозиторий и подключайте ко всем проектам. Я надеюсь ваше приложение позволяет хранить модули, которые не используются.

Давайте заканчивать с пустыми папками. Воспринимайте это как данность. Никто еще не умер от этого.
Пустые папки создаются только один раз при разворачивании проекта. А если вы это регулярно делаете, тогда это вопрос организации сборки и деплоя.

git stash save «my stash name»

> 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой)
Я плачу 200 руб в мес и не напрягаюсь. Кредитка? Это разве проблема?
Можно сделать по-другому: положить репо на публичный сервер и ходить к нему по SSH.

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

> А топик «Git vs Hg» будет очевидно однобок
А ты все равно напиши с соответствующим дисклеймером. По крайней мере я смогу оценить его с точки зрения Git и оценить его (git) слабые стороны.

Да. У каждого СВОЙ локальный репозиторий со всей историей.
И центральный репозиторий — это не больше чем соглашение, что конкретно именно эта копия будет использоваться для обмена.

Вся децентрацизация крутится вокруг обмена патчами:
— Положите bare-репозиторий на публичный сервер и обменивайтесь информацией через него.
— Можно работать с системой форков, как это устроено на GitHub — здесь неограниченная связь многие ко многим.
— Можно коннектиться напрямую через SSH. Это может быть оправдано, когда вас всего двое.
— Можно обмениваться патчами по почте: git format-patch, git send-email, git apply или git am

Все зависит от того, как у вас организована работа в команде. Наиболее простой и удобный способ — это выделить один репозиторий для обмена. А уж комбинировать все указанные выше способы вы можете как угодно в соответствии с потребностями.

Это махровая безграмотность :)

У меня есть аналогичный проект, занимает 100М. Git репозитарий со всей историей занимает не на много больше.

> вы пробовали пользоваться другими DVCS
Нет не довелось, а на экперименты у меня нет возможностей. Хотя, раз пошла такая пьянка, подниму небольшой проектик на чем-нибудь еще. Но git меня устраивает дальше некуда.

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

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

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

> которую не пинал только ленивый
И буду пинать — до черта людей дальше SVN не видят.

> где-то месяца 4 воевал с git
А я не воевал, а радовался во всю. В чем подвох?

> Git — далеко не лучший представитель этого семейства
А почему бы не написать свой обзор? Я бы почитал с удовольствием.

Про ограничение доступа:
Почитайте эту статью: habrahabr.ru/blogs/Git/75990/
Там автор использует 2 репозитария: 1 — PROD-репо, с ограниченным доступом и второй — песочница для разработчиков.

> Работа над несколькими проектами с общими компонентами
см. git help submodule
В проект можно подключить другие репозитарии как субмодули. Т.е. каждый компонент выделяете в отдельный репозитарий, и подключаете в любых проектах.

Спасибо, добавил в список.

> Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут
Могут напрямую через ssh

> И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши.
Не ленитесь учиться. Я себя очень часто заставляю залезать в хелп или гуглить, чтобы понять как что-то работает.

Черт, промахнулся. Ответил ниже.

> какой командой надо помечать файлы в которых я разрешил конфликты
git add path/to/file

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

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

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

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

Теоретически можно, если еще опустить вопросы очередности выполения, и сложных/множества запросов для data migration. А как тогда быть с номером версии БД. Может получится так, что написали одну миграцию, а номер скакнул на 10. А не скакать нельзя — это ролбек. Да и с ролбеком будут проблемы.
Нет, плохая идея.
Это на совести разработчика и мануала с best practice

Технически — легко.

Это уже недостатки текущей реализации. Единственную сложность, которую я вижу, это невозможность автоматом откатить сложную миграцию, если она упала.
А ваш товарищ, наверное, пришет атомарные миграции.
Все остальное есть куда допиливать, если еще не допилили во второй доктрине.

Ну и здесь используются без проблем. В чем суть спора?

см. symfony doctrine:generate-migrations-diff

> Ей Богу, проще ручками в базе поправить, полученный SQL-код записать в отдельный sql-файл и, при случае, использовать. Меньше проблем, меньше времени, ничего не надо изучать.

Я про то и писал, что на определенном уровне разработке это намного сложнее, чем использовать миграции.

Нет. Я не уверен, надо посмотреть исходники, но доктрина оборачивает миграцию в транзакцию и это не спасает. Еще я не знаю дружат ли ALTER и CREATE TABLE с транзакциями. Надо порыться в доке к БД. Или может кто подскажет?