А про добавление колонок на больших таблицах — здесь хорошо описано:
Опыт 1440 миграций баз данных — habr.com/company/wrike/blog/414441
Колонка добавляется как nullable ну и дальше аккуратно заполняется.
ORM в миграциях нужна не столько для «удобства», сколько для потенциальной возможности смены СУБД
В миграциях этого точно не нужно — они одноразовые.
Транзакции в DDL
НЕ все базы поддерживают транзакции на уровне запросов по изменению структуры БД.
Долго работал и мучался с MySQL, у которой этого не было. Как там сейчас уже не в теме.
Естественно надо подбирать целевую аудиторию. Но это, конечно, может быть не просто, если ваша аудитория топ-менеджеры, например. Но всегда можно что-то придумать.
Git-way: один модуль — один репозиторий. Можно конечно объедить группу репозиториев в суперрепозиторий, но обновляться будет не совсем удобно. Не пробовал.
Или положите все в один репозиторий и подключайте ко всем проектам. Я надеюсь ваше приложение позволяет хранить модули, которые не используются.
Давайте заканчивать с пустыми папками. Воспринимайте это как данность. Никто еще не умер от этого.
Пустые папки создаются только один раз при разворачивании проекта. А если вы это регулярно делаете, тогда это вопрос организации сборки и деплоя.
> 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой)
Я плачу 200 руб в мес и не напрягаюсь. Кредитка? Это разве проблема?
Можно сделать по-другому: положить репо на публичный сервер и ходить к нему по SSH.
И как-то непонятно у вас организована командная работа. Я не могу оценить, но думаю, что можно сделать лучше.
> А топик «Git vs Hg» будет очевидно однобок
А ты все равно напиши с соответствующим дисклеймером. По крайней мере я смогу оценить его с точки зрения Git и оценить его (git) слабые стороны.
Да. У каждого СВОЙ локальный репозиторий со всей историей.
И центральный репозиторий — это не больше чем соглашение, что конкретно именно эта копия будет использоваться для обмена.
Опыт 1440 миграций баз данных — habr.com/company/wrike/blog/414441
Колонка добавляется как nullable ну и дальше аккуратно заполняется.
В миграциях этого точно не нужно — они одноразовые.
НЕ все базы поддерживают транзакции на уровне запросов по изменению структуры БД.
Долго работал и мучался с MySQL, у которой этого не было. Как там сейчас уже не в теме.
Или положите все в один репозиторий и подключайте ко всем проектам. Я надеюсь ваше приложение позволяет хранить модули, которые не используются.
Пустые папки создаются только один раз при разворачивании проекта. А если вы это регулярно делаете, тогда это вопрос организации сборки и деплоя.
Я плачу 200 руб в мес и не напрягаюсь. Кредитка? Это разве проблема?
Можно сделать по-другому: положить репо на публичный сервер и ходить к нему по SSH.
И как-то непонятно у вас организована командная работа. Я не могу оценить, но думаю, что можно сделать лучше.
А ты все равно напиши с соответствующим дисклеймером. По крайней мере я смогу оценить его с точки зрения Git и оценить его (git) слабые стороны.
И центральный репозиторий — это не больше чем соглашение, что конкретно именно эта копия будет использоваться для обмена.