ну вы можете и это забыть, начать дальше кодить, а потом запушить... в принципе максимум конфликт руками решать придется, но все же... проще приучить себя пушить ;)
нормально, откуда там вечные циклы.
единственное, пул на рабочую копию с локальными изменениями может потребовать дополнительных телодвижений (stash изменений, конфликты)... решаемо, но будет злить ;) это я про случай, если вы изменения запушили и при этом ещё их синкнули с другой рабочей копией (там они как незакомиченные изменения)
Суть совета - комитить и пушить работу в отдельную ветку на одном компьютере, и пулить ее на другом, и продолжать работать. По окончанию работы - мержить эту ветку в основную, с которой работает ваш сайт
Тут мое имхо, не как юриста - 393 могла бы покатить, но есть нюансы. И все они зависят от заключенного с исполнителем договора. 393 может быть применена только в случае _противоправных_ действий исполнителя. Т.е. как минимум в договоре должно быть указание о сохранении прежнего функционала. А скорее всего, полный перечень этого функционала, ибо "прежний объем" - понятие недоказуемое. Второе, что потребуется доказать - что причина сбоя именно действия Исполнителя, т.е. привлекать экспертизу. Ну и третье, что приходит в голову - нужно будет доказать, что никакие изменения не вносились после работы исполнителя. Ну а дальше все вопрос суда. Попробовать подать можно, но вот выиграть....
Ну а "как защититься" - видно выше, четко описать в договоре функционал.
Если у вас для каждый комит обеспечивает консистентность между кодом, схемой базы и заполнением фейковых данных, то совершенно ничего не мешает при переключении веток удалять базу и исполнять все с нуля. Все же предполагается, что вы работаете с одной веткой, а не кодите одной рукой в одной ветке, а другой - во второй.
Igor, нет, у него свой индекс, свое хранилище, это совсем отдельное ПО. Данные перегоняются текстом - селект из мускуля, запрос на добавление в Solr. А поскольку Solr или ElasticSearch (оба, кстати, построены на одном движке Lucene) не реляционные базы, структуры данных могут быть совсем другие, именно те, которые оптимальны для поиска. Т.е. это в мускуле у вас таблица продуктов, таблица заказов, таблица остатков, а в Эластик может попасть сводный документ со всеми этими данными сразу, а может и еще какими-то данными, взятыми из других источников (например, частота просмотров страниц может идти сразу в Эластик, так как там она нужна для аналитики, а в реляционной базе - просто не нужна). Ну, минус - приходится заботится об актуальности данных, копии которых хранятся в разных СУБД (и как правило это задача разработчика)
Виктор: Хм, нужно исследовать, на самом деле припоминаю, что в 2.5 они там что-то делали, но там еще зависит от типа связи. У доктрины с eager раньше вылезали всякие баги, так что я стараюсь не смотреть в эту сторону, а всегда использовать DQL с нужными joinами.
GavriKos: батарейка там для других целей - работы светодиодов и работы радиопередатчика (отдельный на 915 MHz, не связанный c rfid), вот полная статья, https://jelmertiete.com/2014/11/17/TML-bracelet-te... вообще заморочились основательно с этими браслетами.
