Преобразование системы исправлений SVN в Git - PullRequest
0 голосов
/ 06 марта 2019

Моя команда поддерживает большую часть программного обеспечения на основе PHP / MySQL, которая в настоящее время использует SVN для контроля версий.

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

В нашем проекте есть программа автообновления, которая обновляет локальную установку до последней версии из репозитория svn, в основном она использует svn update плюс некоторые другие не относящиеся к делу операции. Я уже перенес это на git pull и т. Д., Это было легко.

Сложность заключается в структуре нашей базы данных / исправлении данных.

Прямо сейчас, если разработчику необходимо обновить схему базы данных или выполнить какую-либо операцию с существующей базой данных, чтобы обновить ее, они создают файл исправления. Этот файл патча нумеруется вручную во время принятия, в соответствии с тем, каким будет номер ревизии следующий svn. Поэтому, если я фиксирую обновление, содержащее патч, я проверяю в журнале svn номер последней ревизии, скажем, 104, и называю свой патч patch_105. Затем программа автообновления запускает svn update и применяет все найденные исправления, которые новее последней установленной версии.

Поток выглядит так:

  1. Текущая редакция: 100
  2. Обновление прессы
  3. Последняя версия 105 кодовой базы извлечена из SVN
  4. Проверить исправления, более новые, чем версия 100
  5. Запустить patch_102, patch_105
  6. Текущая версия сейчас 105

Переход к git теперь создает проблему, так как git не работает без номеров ревизий, поэтому система последовательных исправлений не может работать таким образом. Я знаю, что мы можем приблизительно получить номер сборки, запустив git rev-list --count HEAD, но работа с ветками и т. Д. Означает, что я не уверен, что есть какая-либо гарантия того, каким может быть следующий номер сборки.

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

Итак, подведем итог, у вас есть процесс обновления, подобный этому в вашем проекте? Если да, то как вы справляетесь с этой проблемой? Должен ли я думать об этом совершенно по-другому?

Спасибо!

...