Управление программным обеспечением с помощью пользовательских локальных исправлений - PullRequest
Новая
       55

Управление программным обеспечением с помощью пользовательских локальных исправлений

1 голос
/ 23 июля 2010

Я пытаюсь найти способ развертывания программного обеспечения с пользовательскими исправлениями в производстве. Базовое программное обеспечение с открытым исходным кодом с собственными репозиториями (SVN), и у нас есть несколько патчей, которые можно выбрать только для одного сервиса, а не для другого (поэтому у нас есть base + patchA + patchB на одном сервере и base + patchA + patchC на другой).

Все будет развернуто как пакеты, что довольно просто. Вопрос, о котором я думаю: как мы храним изменения? Вот несколько способов, о которых я подумал:

  • Я пытался использовать серию quilt / patch + загрузка определенной ревизии из апстрима при сборке. Это работает хорошо, пока нам не нужно портировать патчи на новую версию. Поскольку для модификации патча quilt требуется копия дерева, на исправление требуется очень много времени. Кроме того, использование разных версий на разных серверах означает, что нам нужны разные сценарии сборки.
  • Я мог бы клонировать репозиторий в локальный git / hg и создать ветку с локальными модификациями. Это отлично подходит для переноса патчей вперед, и я могу делать локальные метки выпуска в своей ветке, но, к сожалению, я теряю информацию об отдельных патчах. Конечно, я могу видеть разницу в верхнем потоке, но я теряю четкое разделение различных локальных модификаций.
  • Я пробовал составлять git / hg-mq, но, насколько я вижу, они не легко экспортируют серии патчей. Они хороши для хранения работы в процессе. Я могу сделать тот же трюк, что и BitBucket, и создать очереди исправлений «внутри репозитория» для их экспорта, но тогда каждая очередь исправлений будет назначена отдельной ветви (такая же модификация потребуется для каждой локальной ветви, для которой используется patchA). пример).

Есть ли у вас другие идеи, статьи, стандартизированные способы сделать это? Дополнительные плюсы и минусы для способов, которые я упомянул?

1 Ответ

0 голосов
/ 03 марта 2012

Я знаю, что прошло много времени с тех пор, как вы спрашивали, но у вас был ответ прямо здесь:

Я мог бы клонировать репозиторий в локальный git / hg и создать ветку с местными модификациями. Это отлично подходит для переноса патчей вперед и я могу сделать локальные метки выпуска на моей ветке, но, к сожалению, я потерять информацию об отдельных патчах. Я могу видеть разницу в вверх по течению, конечно, но я теряю четкое разделение различных местных модификаций.

Вы по-прежнему получаете четкое разделение различных локальных модификаций с помощью механизма комита Git.

На мой взгляд, Git "commit" - это то же самое, что патч, отправленный по электронной почте. То есть он включает одно изменение в строке темы и в тексте с описанием, объясняющим причину изменения. Конечно, он также содержит изменения для всех соответствующих файлов.

Команда git format-patch (и ее двоюродная сестра, git send-email) на самом деле будут выводиться в этом формате, если вам нужно отправить изменения во внешнюю систему (например, в восходящий поток), но информация в любом случае есть.

...