Структура проекта SVN и стратегия ветвления для нескольких проектов, которые иногда перекрываются.

Question

Я пытаюсь создать сплошную структуру хранилища SVN и стратегию ветвления для небольшой группы из четырех человек. У нас есть четыре крупных и несколько второстепенных проектов в разработке в любой момент времени, и часто существует некоторое совпадение между проектами. Наша текущая стратегия полностью неэффективна и состоит в том, что каждая из этих папок (примерно 15 или около того) находится под одной версией «trunk». Это означает, что всякий раз, когда мы вступаем в ветвь, мы делим все 15 проектов (для обновления рабочей копии требуется 20 минут, чтобы развернуть ветку, чтобы это было в перспективе).

Основная проблема заключается в том, что некоторые проекты перекрываются, и нет ничего необычного в том, что функция или задача требуют изменения чего-либо в Project A, а также в Project B (все эти проекты говорят с одной и той же базой данных и используют одну и ту же базу данных таблицы, кроме того, они разделяют бизнес-уровень, так что изменение класса в одном проекте будет влиять на другое), поскольку все проекты являются существенно связанными частями одного «зонтичного» приложения. В качестве примера, для крупных проектов, есть в основном:

• Проект A: Фронтальный электронной коммерции сайт
• Проект B: система Back-конец исполнение/управление
• Проект C: клейма копия от переднего конца участка (стили же минус CSS и с меньшей функциональностью)
• Project D: Web Service API

а и в связаны между собой, но B представляет собой программное приложение-как-услуга (мы действуем как наш собственный клиент) с C как это передний конец для клиентов (A служит передним для нашей собственной компании, поскольку C по существу A с меньшими возможностями и без специфических для компании деталей). D доступен только клиентам, но моя конечная цель - использовать функции A, B и C, используя функциональные возможности D через веб-службы (в основном, в нашем собственном докторе).

Мы только что решили пойти с трехнедельной стратегией развертывания (что означает, что мы занимаемся производством каждые три недели), и наша текущая стратегия SVN является громоздкой и делает ветвление чрезвычайно болезненным.

С несколькими проектами, имеющими перекрытие, имеет ли смысл держать их всех в одной папке проекта с форматами филиалов/тэгов/транков, или мы должны рассматривать их как отдельные проекты? Может быть, объединить некоторые, например, с интерфейсом SaaS/backend вместе с нашим отдельным сайтом и веб-сервисом отдельно?

Любые предложения или рекомендации от людей, участвующих в подобных проектах, были бы замечательными.

Answer 1

Это похоже на проекты в моей компании. У нас та же проблема, мы молча отказались от использования одной и той же базы кода для всего и разделили все на отдельные проекты, потому что было проще управлять этим способом. Если возможно, вы также можете создавать отдельные проекты для общего кода, которые у вас есть, а затем ссылаться на DLL из этих проектов во всех ваших других проектах. Я сделал последнее в своей последней компании, и это работает. Это просто означает, что вы должны помнить, чтобы скопировать последнюю dll в ваш текущий проект, если вы обновите общий код.

Answer 2

Я хотел бы попробовать что-то вроде этого:

D - Сделать это отдельный репо. Включите в другие репозитории, где необходимо использовать svn: externals.
B - Сделайте это отдельным репо. Включите в другие репозитории, где необходимо использовать svn: externals.
A - Сделайте это отдельным репо, и это может быть багажник.
C - Используйте тот же репо, что и A, но сделайте это своей ветвью. Любые функции из туловища, которые вы хотите выставить клиентам, вы сливаетесь в эту ветку с багажника.