Как правильно организовать контроль и управление файлами проектов

Главные вкладки

Аватар пользователя VLAD_X VLAD_X 21 августа 2007 в 17:44

Недавно здесь пролетала заметка об организации контроль файлов при помощи Git, довольно интересная вещь. Но в ней описана реализация только для одного независимого проекта.
При желании добавить ещё один проект в репозитарий (или создать новый репозитарий для нового проекта) придётся целиком и полностью копировать весь код Друпала и модулей со всеми внесёнными изменениями.
Последние несколько дней пытаюсь реализовать задуманное при помощи SVN. Примерная и желаемая структура хранилищ приведена на картинке.

Условия: необходимо вынести оригинальный код Друпала в отдельную ветку (ветка - это условно, можно сделать отдельный репозитарий или branch); назовём её drupal/original.
Также необходимо как-то отделить собственные изменения в ядре Друпала (да, не всё можно сделать при помощи модулей, приходится и ядро ковырять) в отдельную ветку; назовём её drupal/modified.
Как обычно, надо иметь branches, tags и trunk.

Аналогичную структуру имеют и модули: cck/original/trunk - последняя оригинальная версия от разработчиков модуля, cck/modified/trunk - последняя моя версия.

Собственно, в ветках drupal и modules хранятся изменения применительные ко всем разрабатываемым сайтам.

А вот в ветках site1 (условно), site2 и т.д. должны храниться рабочие копии с правками для каждого конкретного сайта. Причём часть файлов берётся из drupal/modified/trunk, часть - из modules/<модуль>/modified/trunk, а ещё часть - свои локально-изменённые файлы. (тот же settings.php или модули, написанные для этого конкретного сайта и больше нигде не используемые).

На этом этапе и возникли проблемы: как поместить в хранилище для конкретного сайта все файлы? Каталоги можно "прилинковать" свойством svn:externals, а файлы - нельзя.

Приглашаю всех обсудить данную тему и использование VCS в составных проектах вообще Smile

ВложениеРазмер
Иконка изображения vcs.gif61.37 КБ

Комментарии

Аватар пользователя squadette squadette 22 августа 2007 в 2:33

а) вот заметка: http://versioncontrolblog.com/2007/08/02/upgrading-drupal-52-with-git/

б) Вы принципиально не поняли идею (или я невнятно описал). изложенная техника тривиально распространяется на любое количество сайтов со своим набором изменений в каждом. достаточно всего лишь клонировать drupal-and-modules в drupal-site1, drupal-site2, etc.

в) Ваши "кое-какие проблемы" на самом деле принципиальные, и Вы не добьётесь от Subversion 1.4.4 функциональности, которая тривиально достигается в Git. это проистекает из-за отсутствия в Svn нормального merge tracking. Его обещают сделать в 1.5, который планируется "когда-нибудь в этом году". Но и тогда я лично не уверен, что там всё сделают правильно.

Увы, к сожалению, всё именно так.

г) Вы, видимо, не до конца понимаете смысл отслеживания сторонних исходников. svn:externals нужен для существенно другого. никакого "линкования" там не требуется. нужно просто слияние изменений из двух линий разработки.

попробуйте поработать с Git по моему рецепту, и через некоторое время многое прояснится.

Аватар пользователя squadette squadette 22 августа 2007 в 2:41

прочитайте, как устроены vendor branches в Subversion:

http://svnbook.red-bean.com/en/1.1/ch07s05.html

изобретать велосипед не требуется, но увы, в svn на текущий момент эта функциональность реализована из рук вон плохо.

Аватар пользователя VLAD_X VLAD_X 22 августа 2007 в 7:53

> попробуйте поработать с Git по моему рецепту, и через некоторое время многое прояснится.
Пробовал. поэтому и возникла проблема масштабируемости

> достаточно всего лишь клонировать drupal-and-modules в drupal-site1, drupal-site2
Вот этого, как раз, делать и не хочется. Ведь получится для КАЖДОГО сайта свой набор drupal-and-modules, хотя у всех сайтов есть много одинаковых модулей, н-р, cck, email, print и т.д.
Соответственно, я должен буду накладывать изменения на каждый модуль в каждой копии drupal-and-modules для каждого сайта?
Хочется вынести эти модули в отдельное хранилище и уже оттуда клонировать их в сайт.

Вообще, существуют 3 вида изменений (патчей):
1) Это обновление оригинального исходного кода Друпал (смена версий)
2) Мои изменения (патчи) кода Друпала, который должны объединяться с изменениями оригинального исходного кода
3) Мои изменения (патчи) кода Друпала для каждого конкретного сайта.

Аналогично и для модулей:
1) Обновление оригинального исходного кода модуля
2) Мои изменения кода модуля
3) Мои изменения кода модуля для каждого конкретного сайта.

Попробуйте организовать хранилище для нескольких сайтов, в каждом из которых присутствуют все вышеописанные изменения.
Я пытаюсь сделать это для 3-х сайтов на Drupal-5.2 и 1-ом на Drupal-4.7 (позже).

Аватар пользователя squadette squadette 22 августа 2007 в 14:09

Нет, drupal-and-modules будет один, содержать объединение всех модулей, используемых на всех сайтах. Если на каком-то сайте модуль не нужен -- просто не надо его включать.

Соответственно, схема drupal + drupal-and-modules + drupal-site * N решает поставленную задачу.

Обновление исходного кода протаскивается по маршруту drupal->drupal-and-modules.

Патчи кода друпала для всех сайтов делаются в drupal-and-modules а затем протаскиваются по маршруту d-a-m -> drupal-siteN.

Патчи кода для конкретного сайта вносятся, натурально, в drupal-siteN

Аватар пользователя squadette squadette 22 августа 2007 в 14:13

Теперь для модулей.

Я понял Вашу задачу, про внесение изменений в модули. Да.

для неё надо ввести новый репозиторий -- drupal-common, который клонирован из drupal-and-modules. В drupal-common будут вноситься изменения в модули и основной код.

Тогда репозитории drupal-siteN надо склонировать именно из drupal-common.

Схему протягивания изменений я могу перерасписать, но вроде как там ничего сложного нет.

Замечу, что эта схема никуда не денется при попытке внедрения любой СКВ, не только Git. Даже в Svn Вам придётся создавать именно такое количество бранчей -- 3 + N. Но в случае с гитом процесс слияния тривиален, а в Subversion Вы быстро взвоете, вручную трекая точки последнего мёрджа.

Как-то так. Спасибо, я внесу изменения в следующую версию статьи.

Аватар пользователя VLAD_X VLAD_X 22 августа 2007 в 14:15

> Если на каком-то сайте модуль не нужен -- просто не надо его включать.
Вы предлагате держать на каждом сайте (физически, в папке sites/all/modules/ ) 100-200 модулей, но использовать (включить через админку) из них 20?

Аватар пользователя VLAD_X VLAD_X 22 августа 2007 в 17:57

Про 200 - это преувеличение, конечно. Но суть это не меняет. И сайтов меньше десятка.
Но ситуация ведь будет развиваться, т.к. я пытаюсь сделать всё это на development-сервере, на котором куча сайтов и гора модулей по определению будет.

Аватар пользователя squadette squadette 22 августа 2007 в 19:28

В принципе никто не мешает в каталоге drupal-siteX убивать модуль через git rm -f -r

тогда исправления в неиспользуемых в этом сайте модулях будут уходить в никуда

svnmerge.py вроде бы прикольный, но как всё же интегрированнее и концептуально чище это сделано в гите!

Аватар пользователя VLAD_X VLAD_X 23 августа 2007 в 14:05

> тогда исправления в неиспользуемых в этом сайте модулях будут уходить в никуда
Не уходят.
Условно говоря, ситуация такая.
Был Друпал 5.1, на своём сайте удалил CHANGELOG.TXT, закоммитил, провёл апгрейд до 5.2 (при этом CHANGELOG.TXT изменился) и на сайте CHANGELOG снова появился, да ещё и с конфликтом.
Аналогично и с неиспользованными модулями.