Как организовать проект или два репозитория в одну папку?

Question

[azverin]

Ломаю голову как лучше организовать структуру проекта.

Пишется:
1. Фреймворк с некой структурой папок.
2. CMS на базе этого фреймворка.

Структура папок в фреймворке следующая:

  common - общие для системы ресурсы (JS, CSS фреймворки)
  files - файлы сохраняемые в системе пользователем (uploads)
  html - верстка
  inc - основная папка системы
      app - классы специфичные для приложения (пустая)
      ctrl - контроллеры (пустая)
      lib - библиотека базовых классов фреймворка
      test - тесты
      tmpl - шаблоны (есть папка default от фреймворка, остальное в .gitignore)
  tmp - временные файлы

Предполагается что и фреймворк, и CMS могут иметь свои файлы в папках common, inc/tmpl, inc/test
Сама CMS живет в inc/app и inc/ctrl. Кастомизация CMS под проект меняет файлы в inc/app, inc/ctrl, html
Вся структура папок уже задана в фреймворке, соотв. CMS надо мягко «наложить» поверх этого.

Хочется вести весь проект в системе контроля версий (СКВ), сейчас это GIT. А в идеале и кастомизацию CMS под конкретный проект также заводить в СКВ, чтобы прозрачно обновлять и фреймворк, и CMS.

Насколько я понимаю механизм externals, можно подключить внешний репозиторий в отдельную папочку и он там будет обновляться, а для CMS нужно внедрение в дерево на нескольких уровнях.

Вариант как сделано в symfony — репозиторий лежит где-то в дебрях, а потом разворачивается запуском скрипта и создает нужную структуру папок мне как-то не очень нравится.

В принципе можно положить два репозитория рядом, а потом их сливать скриптами, но может есть какие-то нормальные варианты? Нельзя ли как-то извернуться с ветками?

UPD: Поразмыслил над ветками, наверное это действительно оптимальный вариант, но есть еще одна сложность. Я хочу чтобы репозиторий с фреймворком и CMS был открытым, а клиентские проекты уже не были доступны широкой публике.
Может быть еще с какими-то проблемами можно столкнуться при ведении кучи веток?

Answer 1

[Nashev]

Пока у вас всего 2 компонента запланировано, пользователю возможно разрешите иметь ещё одну для своих доработок. Каждый из них может подменить своими некоторые файлы более глубокого слоя, и пользоваться этими перекрытыми в случае необходимости. Лучше, когда код разных уровней не смешивается.

Наверняка можно сделать в фреймворке папки для этих «перекрытий», по сути повторяющие оригинальную структуру, и одну функцию для определения пути для любого используемого файла, который ищет в этих трёх (а не 100500) возможных местах… И пользоваться всеми файлами через неё…

Хотя — это вариант переделать фреймворк, а это может быть невозможно. Можно попробовать держать в одной папке два репозитория РАЗНЫХ СКВ — git и hg, например, или git и svn. И для каждой из этих систем держать свой комплект списка игноров и вести его… С другой стороны, если CMS вносит свои изменения в файлы (те же шаблоны, например) фреймворка — то один файл в двух версиях Вам понадобится, а в одной папке этого точно не сделать.

Есть вариант разные ветки одного репозитория иметь, и время от времени в ветку с CMS мёржить без слияния правки из ветки фреймворка… Тоже возможный вариант, да… Может, даже лучший в описанной ситуации. Вы про этот вариант в UPD писали?

Comments

[azverin]

Сейчас автолодер сначала ищет в app, потом в lib, так что переопределение существующих классов происходит прозрачно без вмешательства в «нижний» слой. Плюс через Dependency Injection можно использовать нужный объект отнаследованный от базовых.

В шаблонах всё немного проще: есть папка от FW «default» где лежат заготовки использующиеся по умолчанию и как пример что как работает. При желании создается файл там, где это нужно и и указывается в настройках того, кто его использует. Вся шаблонизация гибкая, везде где используется шаблон можно его переназначить. Т.е. CMS не трогает файлы FW, а кладет свои рядом.

По сути проблема в том, что FW это не просто библиотека, которую можно прицепить сбоку, а каркас, в этом его ценность.
Можно конечно не заморачиваться и вести разработку только CMS, но хочется иметь возможность использовать FW там, где не нужна вся остальная логика и обвязка.

Другой момент, что редакции CMS могут быть разными, соотв. FW является тем общим, что нужно выделять в любом случае.

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

[Nashev]

Ну, подстав там нету, нужно лишь при мёрже не забыть режим «Squash — Just merge change from the other branch. Can't recorder Merge information. The new commit will not record merge branch as one parent commit. Log view will not show merge line between two branch.»