Difference between revisions of "Repo.php"
From Wiki4Intranet
(→Системные требования) |
|||
| Line 4: | Line 4: | ||
Теоретически, вместо него можно было бы использовать просто подмодули Git’а (git submodules), но у них есть определённые минусы: | Теоретически, вместо него можно было бы использовать просто подмодули Git’а (git submodules), но у них есть определённые минусы: | ||
| − | # Когда модулей под сотню — они '''медленные''', ибо | + | # Когда модулей под сотню — они '''медленные''', ибо: |
#* Не умеют делать shallow клоны, всегда клонируют модули полностью. | #* Не умеют делать shallow клоны, всегда клонируют модули полностью. | ||
#* Не поддерживают параллельное обновление. | #* Не поддерживают параллельное обновление. | ||
| Line 12: | Line 12: | ||
#* Следовательно, репозиторий сборки должен являться клоном core с расширениями, подключёнными сабмодулями в <tt>extensions/ExtensionName</tt>. Изменения ядра в таком случае будут перемешиваться с изменениями модулей. | #* Следовательно, репозиторий сборки должен являться клоном core с расширениями, подключёнными сабмодулями в <tt>extensions/ExtensionName</tt>. Изменения ядра в таком случае будут перемешиваться с изменениями модулей. | ||
#: А это неудобно, так как хочется отделить репозиторий «сборки» от кода и дать возможность легко клонировать сборки, создавать свои сборки, дополненные какими-то расширениями и т. п. | #: А это неудобно, так как хочется отделить репозиторий «сборки» от кода и дать возможность легко клонировать сборки, создавать свои сборки, дополненные какими-то расширениями и т. п. | ||
| + | #: Как вариант, можно было уйти от стандартного MediaWikовского расположения кода и поместить core в отдельную подпапку. | ||
# Есть различные неудобства и недостатки функционала: | # Есть различные неудобства и недостатки функционала: | ||
#* В .gitmodules нельзя указать желаемые ветки модулей (например, «хочу ParserFunctions REL1_20»). Опять-таки предполагается, что за версией модуля разработчик следит сам. | #* В .gitmodules нельзя указать желаемые ветки модулей (например, «хочу ParserFunctions REL1_20»). Опять-таки предполагается, что за версией модуля разработчик следит сам. | ||
| Line 17: | Line 18: | ||
#* git archive не работает с сабмодулями — если хочется распространять архив с кодом всей сборки, нужно писать отдельный скрипт. | #* git archive не работает с сабмодулями — если хочется распространять архив с кодом всей сборки, нужно писать отдельный скрипт. | ||
#* Не поддерживаются различные способы доступа к одному репозиторию, например http на чтение для всех и ssh на запись для разработчиков. | #* Не поддерживаются различные способы доступа к одному репозиторию, например http на чтение для всех и ssh на запись для разработчиков. | ||
| + | #: То есть, если хочется нормально push’ить с использованием ssh-ключа, то нужно заставлять '''всех''' клонировать всё исключительно по ssh. | ||
Часть этих проблем можно решить с помощью хелперов или bash-скриптов, однако мы решили сразу написать цельный инструмент. | Часть этих проблем можно решить с помощью хелперов или bash-скриптов, однако мы решили сразу написать цельный инструмент. | ||
Revision as of 14:07, 25 April 2013
repo.php — скрипт обновления/установки, созданный нами и применяемый в Mediawiki4Intranet.
Зачем нужен собственный скрипт?
Теоретически, вместо него можно было бы использовать просто подмодули Git’а (git submodules), но у них есть определённые минусы:
- Когда модулей под сотню — они медленные, ибо:
- Не умеют делать shallow клоны, всегда клонируют модули полностью.
- Не поддерживают параллельное обновление.
- Сабмодули не могут работать с типичным расположением кода MediaWiki (если не клонировать репозиторий ядра), ибо:
- Нельзя создать репозиторий, корень которого был бы submodule’ем.
- Внутрь одного submodule нельзя поместить другой, не трогая репозиторий submodule.
- Следовательно, репозиторий сборки должен являться клоном core с расширениями, подключёнными сабмодулями в extensions/ExtensionName. Изменения ядра в таком случае будут перемешиваться с изменениями модулей.
- А это неудобно, так как хочется отделить репозиторий «сборки» от кода и дать возможность легко клонировать сборки, создавать свои сборки, дополненные какими-то расширениями и т. п.
- Как вариант, можно было уйти от стандартного MediaWikовского расположения кода и поместить core в отдельную подпапку.
- Есть различные неудобства и недостатки функционала:
- В .gitmodules нельзя указать желаемые ветки модулей (например, «хочу ParserFunctions REL1_20»). Опять-таки предполагается, что за версией модуля разработчик следит сам.
- Неудобно переключать сабмодули между разными репозиториями — например, Wikimedia → наш_Github или наш_Github → ваш_форк.
- git archive не работает с сабмодулями — если хочется распространять архив с кодом всей сборки, нужно писать отдельный скрипт.
- Не поддерживаются различные способы доступа к одному репозиторию, например http на чтение для всех и ssh на запись для разработчиков.
- То есть, если хочется нормально push’ить с использованием ssh-ключа, то нужно заставлять всех клонировать всё исключительно по ssh.
Часть этих проблем можно решить с помощью хелперов или bash-скриптов, однако мы решили сразу написать цельный инструмент.
Возможности repo.php
- Установка «сборок» на основе их описаний в ini-файлах, содержащих адреса репозиториев и имена требуемых веток
- Поддержка shallow checkout, «быстрых» рабочих копий для установки (method=ro) и «медленных» для разработки (method=rw)
- Быстрое обновление установленного кода на основе файла индекса, содержащего хеши ревизий
- Полное обновление всех модулей (что-то вроде git submodule foreach 'git pull')
- Параллельное обновление с красивым одновременным выводом состояния на экран с помощью escape-последовательностей (естественно, UNIX only)
- Поддержка произвольного расположения вытаскиваемых рабочих копий (в том числе друг внутри друга)
- Создание архива с полным кодом сборки
- Автоматическое переключение между разными репозиториями одного модуля
- Возможность легкого добавления поддержки нужных систем контроля версий (которая, правда, пока что не пригодилась)
Системные требования
- Нормальная система (не винда) — Linux, FreeBSD или что-то подобное
- PHP 5.3 или новее
- Расширение pcntl
