Difference between revisions of "Repo.php"

From Wiki4Intranet
Jump to: navigation, search
Line 9: Line 9:
 
# Сабмодули не могут работать с типичным расположением кода MediaWiki ''(если не клонировать репозиторий ядра)'', ибо:
 
# Сабмодули не могут работать с типичным расположением кода MediaWiki ''(если не клонировать репозиторий ядра)'', ибо:
 
#* Нельзя создать репозиторий, корень которого был бы submodule’ем.
 
#* Нельзя создать репозиторий, корень которого был бы submodule’ем.
#* Внутрь одного submodule нельзя поместить другой, не трогая репозиторий submodule.
+
#* Внутрь одного модуля нельзя поместить другой, не трогая его репозиторий.
 
#* Следовательно, репозиторий сборки должен являться клоном core с расширениями, подключёнными сабмодулями в <tt>extensions/ExtensionName</tt>. Изменения ядра в таком случае будут перемешиваться с изменениями модулей.
 
#* Следовательно, репозиторий сборки должен являться клоном core с расширениями, подключёнными сабмодулями в <tt>extensions/ExtensionName</tt>. Изменения ядра в таком случае будут перемешиваться с изменениями модулей.
 
#: А это неудобно, так как хочется отделить репозиторий «сборки» от кода и дать возможность легко клонировать сборки, создавать свои сборки, дополненные какими-то расширениями и т. п.
 
#: А это неудобно, так как хочется отделить репозиторий «сборки» от кода и дать возможность легко клонировать сборки, создавать свои сборки, дополненные какими-то расширениями и т. п.
#: Как вариант, можно было уйти от стандартного MediaWikовского расположения кода и поместить core в отдельную подпапку.
+
#: Разве что можно было уйти от стандартного MediaWikовского расположения кода и поместить core в отдельную подпапку.
 
# Есть различные неудобства и недостатки функционала:
 
# Есть различные неудобства и недостатки функционала:
 
#* В .gitmodules нельзя указать желаемые ветки модулей (например, «хочу ParserFunctions REL1_20»). Опять-таки предполагается, что за версией модуля разработчик следит сам.
 
#* В .gitmodules нельзя указать желаемые ветки модулей (например, «хочу ParserFunctions REL1_20»). Опять-таки предполагается, что за версией модуля разработчик следит сам.
#* Неудобно переключать сабмодули между разными репозиториями — например, <tt>Wikimedia &rarr; наш_Github</tt> или <tt>наш_Github &rarr; ваш_форк</tt>.
+
#* Переключать один и тот же модуль между разными репозиториями нужно руками — например, <tt>Wikimedia &rarr; наш_Github</tt> или <tt>наш_Github &rarr; ваш_форк</tt>.
 
#* git archive не работает с сабмодулями — если хочется распространять архив с кодом всей сборки, нужно писать отдельный скрипт.
 
#* git archive не работает с сабмодулями — если хочется распространять архив с кодом всей сборки, нужно писать отдельный скрипт.
 
#* Не поддерживаются различные способы доступа к одному репозиторию, например http на чтение для всех и ssh на запись для разработчиков.
 
#* Не поддерживаются различные способы доступа к одному репозиторию, например http на чтение для всех и ssh на запись для разработчиков.
 
#: То есть, если хочется нормально push’ить с использованием ssh-ключа, то нужно заставлять '''всех''' клонировать всё исключительно по ssh.
 
#: То есть, если хочется нормально push’ить с использованием ssh-ключа, то нужно заставлять '''всех''' клонировать всё исключительно по ssh.
 +
#* В различных ситуациях встречаются различные глюки. Например, «You are on a branch yet to be born» после неудачной попытки добавить submodule.
  
 
Часть этих проблем можно решить с помощью хелперов или bash-скриптов, однако мы решили сразу написать цельный инструмент.
 
Часть этих проблем можно решить с помощью хелперов или bash-скриптов, однако мы решили сразу написать цельный инструмент.

Revision as of 14:18, 25 April 2013

repo.php — скрипт обновления/установки, созданный нами и применяемый в Mediawiki4Intranet.

Зачем нужен собственный скрипт?

Теоретически, вместо него можно было бы использовать просто подмодули Git’а (git submodules), но у них есть определённые минусы:

  1. Когда модулей под сотню — они медленные, ибо:
    • Не умеют делать shallow клоны, всегда клонируют модули полностью.
    • Не поддерживают параллельное обновление.
  2. Сабмодули не могут работать с типичным расположением кода MediaWiki (если не клонировать репозиторий ядра), ибо:
    • Нельзя создать репозиторий, корень которого был бы submodule’ем.
    • Внутрь одного модуля нельзя поместить другой, не трогая его репозиторий.
    • Следовательно, репозиторий сборки должен являться клоном core с расширениями, подключёнными сабмодулями в extensions/ExtensionName. Изменения ядра в таком случае будут перемешиваться с изменениями модулей.
    А это неудобно, так как хочется отделить репозиторий «сборки» от кода и дать возможность легко клонировать сборки, создавать свои сборки, дополненные какими-то расширениями и т. п.
    Разве что можно было уйти от стандартного MediaWikовского расположения кода и поместить core в отдельную подпапку.
  3. Есть различные неудобства и недостатки функционала:
    • В .gitmodules нельзя указать желаемые ветки модулей (например, «хочу ParserFunctions REL1_20»). Опять-таки предполагается, что за версией модуля разработчик следит сам.
    • Переключать один и тот же модуль между разными репозиториями нужно руками — например, Wikimedia → наш_Github или наш_Github → ваш_форк.
    • git archive не работает с сабмодулями — если хочется распространять архив с кодом всей сборки, нужно писать отдельный скрипт.
    • Не поддерживаются различные способы доступа к одному репозиторию, например http на чтение для всех и ssh на запись для разработчиков.
    То есть, если хочется нормально push’ить с использованием ssh-ключа, то нужно заставлять всех клонировать всё исключительно по ssh.
    • В различных ситуациях встречаются различные глюки. Например, «You are on a branch yet to be born» после неудачной попытки добавить submodule.

Часть этих проблем можно решить с помощью хелперов или bash-скриптов, однако мы решили сразу написать цельный инструмент.

Возможности repo.php

  • Установка «сборок» на основе их описаний в ini-файлах, содержащих адреса репозиториев и имена требуемых веток
  • Поддержка shallow checkout, «быстрых» рабочих копий для установки (method=ro) и «медленных» для разработки (method=rw)
  • Быстрое обновление установленного кода на основе файла индекса, содержащего хеши ревизий
  • Полное обновление всех модулей (что-то вроде git submodule foreach 'git pull')
  • Параллельное обновление с красивым одновременным выводом состояния на экран с помощью escape-последовательностей (естественно, UNIX only)
  • Поддержка произвольного расположения вытаскиваемых рабочих копий (в том числе друг внутри друга)
  • Создание архива с полным кодом сборки
  • Автоматическое переключение между разными репозиториями одного модуля
  • Возможность легкого добавления поддержки нужных систем контроля версий (которая, правда, пока что не пригодилась)

Системные требования

  • Нормальная система (не винда) — Linux, FreeBSD или что-то подобное
  • PHP 5.3 или новее
  • Расширение pcntl