Управление изменениями на примере WordPress

Продолжая начатую тему расскажу как я использую Subversion для управления исходными кодами сайта developers.org.ua. Конкретно о том, как поддерживать up-to-date копию WordPress вместе со своими изменениями.

Проблема в следующем. Проект включает в себя исходники внешних проектов (собственно WordPress и различные плагины к нему) плюс мои модификации к нему плюс файлы созданные «с нуля». По хорошему, вносить изменения в исходники чужих библиотек — последнее дело, т.к. обрекаешь себя на вечную поддержку своих патчей к каждой новой версии. С другой стороны — иногда это единственный способ достичь желаемого.

К счастью, приличная система управления конфигурациями позволяет здорово упростить и максимально автоматизировать такую задачу. В частности, Subversion (как и CVS, от которой она недалеко ушла в этом отношении) поддерживает т.н. vendor branches.

A vendor branch is a directory tree in your own version control system that contains information provided by a third-party entity, or vendor. Each version of the vendor’s data that you decide to absorb into your project is called a vendor drop.

В двух словах алгоритм таков: сохраняя каждый релиз WordPress как vendor drop в Subversion мы можем вычислить разницу (diff) между любыми двумя релизами и затем применить (merge) ее к актуальной копии, которая содержит наши изменения.

Теперь на пальцах.

Дерево проекта выглядит следующим образом:

/
  3rd-party/
  www/
  ...

В 3rd-party целиком импортируется каждый новый релиз WordPress, в www хранятся файлы которые копируются на веб-сервер (включая свою копию файлов WordPress вместе с моими изменениями).

Наиболее трудоемкая часть работы — правильно выстроить цепочку vendor drops. Для этого мало просто импортировать каждый новый релиз, необходимо копировать каждый новый релиз поверх предыдущего, описывая разницу для Subversion. И создавать тег для каждого релиза, чтобы указать его при выполнении обновления.

Предположим, что актуальная копия (в www) содержит WordPress 1.5.1.3 и мы хотим обновить ее до версии 1.5.2. Создаем vendor drops:

$ svn import wordpress \
svn://repository-path/3rd-party/wordpress-current \
-m ’added WP release 1.5.1.3′
$ svn copy svn://repository-path/3rd-party/wordpress-current \
svn://repository-path/3rd-party/wordpress-1.5.1.3 \
-m ’tagged WP release 1.5.1.3′
# копируем релиз 1.5.2 поверх копии wordpress-current
$ cd wordpress-current
# svn add/mv/rm при необходимости и фиксируем изменения
$ svn ci -m ’upgraded WP to 1.5.2′
$ svn copy svn://repository-path/3rd-party/wordpress-current \
svn://repository-path/3rd-party/wordpress-1.5.2 \
-m ’tagged WP release 1.5.2′

Теперь репозиторий выглядит следующим образом:

  3rd-party/
    wordpress-1.5.1.3/
    wordpress-1.5.2/
    wordpress-current/
  www/
  ...

Выполняем обновление:

$ cd ../../www/
$ svn merge svn://repository-path/3rd-party/wordpress-1.5.1.3 \ 
svn://repository-path/3rd-party/wordpress-1.5.2 \
wordpress
U wordpress\wp-includes\template-functions-category.php
...
U wordpress\wp-admin\categories.php
$ svn ci -m ’upgraded web copy to WP 1.5.2′

Все. :)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU