Быстрое обновление RotorCMS (Рейтинг: +4)
Написал проект на роторе. Пока писал проект вышел laravel 9 и обновился ротор. Пришлось обновляться и без неприятностей не обошлось. Очень неудобно смотреть кормиты и сравнивать со своим кодом в проекте. Где-то скопировал криво, где объединил весь файл, а там были моим изменения. В итоге пришлось все по новой тестировать, просматривать все страницы и код. А чем дольше не обновляешь, тем более сложнее потом переработать все новые обновления которых очень много. В чатике по Laravel не привыкли видеть такие cms которые переписывают код, как мне там дали понять, что cms должна предоставлять наследование контроллеров. Поэтому в чате не пришлось ожидать помощи. Нужен был инструмент слияния файлов таким образом, что бы наши файлы проекта не переписывались, а новый код добавлялся. Ничего подобного нагуглить не вышло. Была попытка написание сравнителя файлов, который генерировал git патчи, но это всё нито.
У git есть софтина merge-file которая оказалась подходящей, но merge-file это трехстороннее объединение. То-есть два файла невозможно объединить, нужен третий базовый, основа на которую накладывается новая версия файла от вантуза и сверху наша. Подсунуть git-merge в качестве базового файла копию своего файла не даст результатов. Значит нам нужен базовый файл, тот на котором были построены наши изменения. Если мы не знаем последний коммит из ротора на котором начал формироваться наш проект, то можно отследить по дате изменения наших файлов. И так нам известен последний коммит репозитория ротора. Клонируем ротор и в его директории откатываемся до нужного нам коммита git checkout commitId. Дальше на этом состоянии вытаскивает базовый файл на котором построены наши изменения. Затем переключаемся на последний коммит ротора просто git checkout master. Тут мы забираем самую новую версию файла выпущенного обновления от Вантуза. И сравниваем git merge-file наш_текущий_файл базовый_файл новый_файл. Происходит идеальное слияние то, что нам нужно, наши изменения не затерты, новый код от Вантуза добавлен, мы рады. Если был конфликт, по меткам в файле все видно и понятно, что из нового файла, а что из нашего, фиксим и готово.
Но конечно это все хорошо, но мы же не можем такие операции проделывать ручками для каждого файла, поэтому был написан nodejs модуль roup. Мне показалось, что для таких дел отлично подходит nodejs и всё на этом.
Апгрейд в действии
У меня версия ротора 10.2 с обновления до лары 9, последний коммит с которого я обновлялся у меня есть, выяснять не пришлось.
В проекте в директории upgrades лежит свежий клонированный репозиторий ротора.
Запускаем roup
Наблюдаем процесс сравнения файлов с файлами нашего проекта, изъятия всех версий файлов и приготовления. В конце будет выведен результат работы. Это обновлённые файлы в нашем проекте, новые файла пришедшие с обновлением и файлы в которых имеется конфликт. Результат также дублируется в лог куда также пишется айди последнего коммита ротора. Берём айди коммита из лога и записываем в наш конфиг в запускаемом файле roup.js, он нам пригодится при следующем обновлении. В моём случаи вышло всего 7 конфликтных файлов и 200 начисто слитых. Процесс обновления прошёл великолепно, и последующие обновления будут сливаться в тот-же день не зная горя.
Процесс установки и использования roup описан в Readme репозиторя https://github.com/oopsfix/roup , здесь его дублировать не стану. На этом прощаюсь, возможно roup вас обрадует как и меня.
Добавил: Reflesh
01.06.2022 / 13:31У git есть софтина merge-file которая оказалась подходящей, но merge-file это трехстороннее объединение. То-есть два файла невозможно объединить, нужен третий базовый, основа на которую накладывается новая версия файла от вантуза и сверху наша. Подсунуть git-merge в качестве базового файла копию своего файла не даст результатов. Значит нам нужен базовый файл, тот на котором были построены наши изменения. Если мы не знаем последний коммит из ротора на котором начал формироваться наш проект, то можно отследить по дате изменения наших файлов. И так нам известен последний коммит репозитория ротора. Клонируем ротор и в его директории откатываемся до нужного нам коммита git checkout commitId. Дальше на этом состоянии вытаскивает базовый файл на котором построены наши изменения. Затем переключаемся на последний коммит ротора просто git checkout master. Тут мы забираем самую новую версию файла выпущенного обновления от Вантуза. И сравниваем git merge-file наш_текущий_файл базовый_файл новый_файл. Происходит идеальное слияние то, что нам нужно, наши изменения не затерты, новый код от Вантуза добавлен, мы рады. Если был конфликт, по меткам в файле все видно и понятно, что из нового файла, а что из нашего, фиксим и готово.
Но конечно это все хорошо, но мы же не можем такие операции проделывать ручками для каждого файла, поэтому был написан nodejs модуль roup. Мне показалось, что для таких дел отлично подходит nodejs и всё на этом.
Апгрейд в действии
У меня версия ротора 10.2 с обновления до лары 9, последний коммит с которого я обновлялся у меня есть, выяснять не пришлось.
В проекте в директории upgrades лежит свежий клонированный репозиторий ротора.
Запускаем roup
node roup
Наблюдаем процесс сравнения файлов с файлами нашего проекта, изъятия всех версий файлов и приготовления. В конце будет выведен результат работы. Это обновлённые файлы в нашем проекте, новые файла пришедшие с обновлением и файлы в которых имеется конфликт. Результат также дублируется в лог куда также пишется айди последнего коммита ротора. Берём айди коммита из лога и записываем в наш конфиг в запускаемом файле roup.js, он нам пригодится при следующем обновлении. В моём случаи вышло всего 7 конфликтных файлов и 200 начисто слитых. Процесс обновления прошёл великолепно, и последующие обновления будут сливаться в тот-же день не зная горя.
Процесс установки и использования roup описан в Readme репозиторя https://github.com/oopsfix/roup , здесь его дублировать не стану. На этом прощаюсь, возможно roup вас обрадует как и меня.
Рейтинг:
+4
Просмотры: 372Комментарии (0) »