Я понял Вашу задачу, про внесение изменений в модули. Да.
для неё надо ввести новый репозиторий -- drupal-common, который клонирован из drupal-and-modules. В drupal-common будут вноситься изменения в модули и основной код.
Тогда репозитории drupal-siteN надо склонировать именно из drupal-common.
Схему протягивания изменений я могу перерасписать, но вроде как там ничего сложного нет.
Нет, drupal-and-modules будет один, содержать объединение всех модулей, используемых на всех сайтах. Если на каком-то сайте модуль не нужен -- просто не надо его включать.
Соответственно, схема drupal + drupal-and-modules + drupal-site * N решает поставленную задачу.
Обновление исходного кода протаскивается по маршруту drupal->drupal-and-modules.
Патчи кода друпала для всех сайтов делаются в drupal-and-modules а затем протаскиваются по маршруту d-a-m -> drupal-siteN.
Патчи кода для конкретного сайта вносятся, натурально, в drupal-siteN
б) Вы принципиально не поняли идею (или я невнятно описал). изложенная техника тривиально распространяется на любое количество сайтов со своим набором изменений в каждом. достаточно всего лишь клонировать drupal-and-modules в drupal-site1, drupal-site2, etc.
Как правильно организовать контроль и управление файлами проектов
хмммм, понятно
можно попробовать
git rerere --help
Как правильно организовать контроль и управление файлами проектов
В принципе никто не мешает в каталоге drupal-siteX убивать модуль через git rm -f -r
тогда исправления в неиспользуемых в этом сайте модулях будут уходить в никуда
svnmerge.py вроде бы прикольный, но как всё же интегрированнее и концептуально чище это сделано в гите!
Как правильно организовать контроль и управление файлами проектов
это реальные цифры или поэтическое преувеличение?
и сколько у Вас сайтов (тоже реальные цифры)?
Как правильно организовать контроль и управление файлами проектов
Теперь для модулей.
Я понял Вашу задачу, про внесение изменений в модули. Да.
для неё надо ввести новый репозиторий -- drupal-common, который клонирован из drupal-and-modules. В drupal-common будут вноситься изменения в модули и основной код.
Тогда репозитории drupal-siteN надо склонировать именно из drupal-common.
Схему протягивания изменений я могу перерасписать, но вроде как там ничего сложного нет.
Как правильно организовать контроль и управление файлами проектов
Нет, drupal-and-modules будет один, содержать объединение всех модулей, используемых на всех сайтах. Если на каком-то сайте модуль не нужен -- просто не надо его включать.
Соответственно, схема drupal + drupal-and-modules + drupal-site * N решает поставленную задачу.
Обновление исходного кода протаскивается по маршруту drupal->drupal-and-modules.
Патчи кода друпала для всех сайтов делаются в drupal-and-modules а затем протаскиваются по маршруту d-a-m -> drupal-siteN.
Патчи кода для конкретного сайта вносятся, натурально, в drupal-siteN
Как правильно организовать контроль и управление файлами проектов
да, есть ещё варианты (оба я не пробовал лично, но вроде как они работают)
а) svnmerge: http://kenkinder.com/svnmerge/
б) svk: http://versioncontrolblog.com/svk/
Как правильно организовать контроль и управление файлами проектов
прочитайте, как устроены vendor branches в Subversion:
http://svnbook.red-bean.com/en/1.1/ch07s05.html
изобретать велосипед не требуется, но увы, в svn на текущий момент эта функциональность реализована из рук вон плохо.
Как правильно организовать контроль и управление файлами проектов
а) вот заметка: http://versioncontrolblog.com/2007/08/02/upgrading-drupal-52-with-git/
б) Вы принципиально не поняли идею (или я невнятно описал). изложенная техника тривиально распространяется на любое количество сайтов со своим набором изменений в каждом. достаточно всего лишь клонировать drupal-and-modules в drupal-site1, drupal-site2, etc.
Drupal 5.2.
Лично я храню свой Drupal под системой контроля версий Git.
Вот инструкция: http://versioncontrolblog.com/2007/08/02/upgrading-drupal-with-git/
Это сложнее, но зато существенно надёжнее и безопаснее.