#php #svn #conflict
#php #svn #конфликт
Вопрос:
switch Я уверен, что я не единственный, кто пытался внести последние изменения в код на реальном сервере из SVN непосредственно перед тем, как отправиться домой, только чтобы обнаружить, что какой-то болван изменил файлы непосредственно на сервере, и теперь у вас есть пять PHP-скриптов, помеченных как конфликтующие, сайт не работает, и на вас кричатна вашей жене за опоздание на ужин, потому что вам пришлось разрешать все конфликты вручную, потому что об откате не может быть и речи.
Я думаю, было бы здорово, если бы существовало расширение для PHP, которое не умирало бы с ошибкой синтаксического unexpected T_SL анализа при обнаружении конфликтующего файла, а вместо этого анализировало бы его, используя только рабочую версию копии каждого конфликта.
<<<<<<< .mine
changes_my_stupid_coworker_made(); // This would be executed
=======
my_important_changes(); // This would NOT be executed
>>>>>>> .r9
Существует ли такое расширение или что-то, что может быть использовано пользователем для аналогичного эффекта?
Комментарии:
1. Я могу только представить, что это будет очень сложный плагин для написания при сохранении производительности… хотя самой проблемы можно избежать, не предоставляя всем доступ к живой среде, черт возьми, если вам нужно внести изменения в живую среду вне системы контроля версий, вы, вероятно, делаете что-то неправильно (в своем рабочем процессе)…
2. Я согласен, никто не должен ничего трогать в живой среде, и наш рабочий процесс строго запрещает делать это без очень веской причины. Тем не менее, это происходит — возможно, потому, что определение «веской причины» сильно варьируется от человека к человеку.
3. Ваши коллеги используют анти-шаблон «дженга». Смотрите Ежедневный WTF: управление выпуском сделано правильно для получения информации об этом. Чтобы принудительно использовать Subversion, используйте предложение JB Nizet об использовании SVN Export и установите его для перезаписи файлов сервера. Чья-то работа потерялась? Черт возьми, они не смогли следовать процессу. Если что-то действительно срочно, скажите им, чтобы они изменили исходные тексты в «помеченной» ветке и уведомили менеджера проекта, чтобы он наладил беспорядок (т. Е. Потребуется новый тег, а старый тег больше не «чистый»).
Ответ №1:
Это действительно был бы худший способ решения проблемы.
- Никогда не позволяйте никому редактировать файлы непосредственно на сервере. Файлы могут быть доступны только для чтения (или виновник может быть уволен)
- Не обновляйте сервер напрямую из репозитория SVN: обновите рабочую копию, запустите все модульные и интеграционные тесты на этой рабочей копии, затем пометьте ревизию и экспортируйте рабочую копию на сервер
Если люди просто не могут работать правильно, не позволяйте им больше работать.
Комментарии:
1. Мы уже помечаем ревизии и используем их в процессе обновления, но они все еще могут конфликтовать, если на сервере есть локальные изменения. Они даже не могут быть обнаружены при тестировании изменений в среде тестирования интеграции. Нам также необходимо разрешить доступ на запись к файлам, потому что в противном
svn switchслучае их тоже нельзя было бы трогать.2. Не заставляйте сервер обслуживать файлы из рабочей копии. Заставьте его обслуживать файлы из экспортированной рабочей копии с ограниченным доступом к файлам.
Ответ №2:
Попробуйте обновить текущую среду, принудительно используя их -полная, все еще может вызвать проблемы (см. Предыдущий комментарий), но это предотвращает возникновение конфликтов. С этого момента вы можете работать над тем, чтобы не вносить изменения в живую среду за пределами контроля версий.
Из головы
svn up --accept theirs-full
Мы убедились, что у всех разработчиков есть способ обновить живую среду, будь она очень строгой. Мы не можем обновлять через командную строку на живых серверах, но у нас есть центральный скрипт на сервере, на котором мы можем настраивать проекты на нем, а затем мы можем давать команды обновления через скрипт. Затем скрипт сначала выполнит diff, проверит конфликты и обновит, если все в порядке, и отправит нескольким людям и руководителю команды, ответственному за проект, электронное письмо с выводом cmd.
Это довольно аккуратно, предотвращает ужасные сбои и действительно поздние ночи.