У вас есть несколько уровней: как организовать единое дерево исходных текстов проекта, как поддерживать разные проекты вместе, как поддерживать зависимости этого проекта, как поддерживать разные варианты каждого проекта и как их упаковать. .
Пожалуйста, имейте в виду, что, что бы вы ни делали, ваш проект в конечном итоге станет достаточно большим, чтобы сделать его неприспособленным. Нормально менять структуру несколько раз за время существования проекта. Когда это произойдет, вы почувствуете, что это больше не правильно: обычно, когда установка вас беспокоит больше, чем помогает.
1 - ведение различных вариантов каждого проекта
У вас нет вариантов для каждого проекта, вы не решите несколько вариантов, поддерживая версии или ветки parralel. Иметь исходное дерево для каждого проекта / библиотеки, которое можно использовать для всех вариантов. Не управляйте различными «ОС», управляйте различными функциями. То есть, есть варианты для таких вещей, как «поддержка posix сокетов» или «поддержка пользовательского интерфейса». Это означает, что если появится новая ОС, вам просто нужно выбрать набор функций, которые она поддерживает, а не запускать новую версию.
Когда требуется конкретный код, создайте интерфейс (абстрактный класс в C ++) и реализуйте поведение по отношению к нему. Это изолирует проблемный код и поможет добавлять новые варианты в будущем. Используйте макрос, чтобы выбрать правильный во время компиляции.
2 - ведение зависимостей каждого проекта
Иметь определенную папку «зависимости», в которой каждая подпапка содержит все необходимое для одной зависимости (то есть включает и подчиненные зависимости). В начале, когда кодовая база не слишком велика, вам не нужно особо заботиться о том, чтобы автоматически обеспечить совместимость всех зависимостей, сохраните ее на потом.
Не пытайтесь объединить зависимости из их корневого расположения выше в иерархии svn. Официально доставляйте каждую новую версию нуждающимся в ней командам, чтобы они могли обновить свою собственную часть SVN вместе с ней.
Не пытайтесь использовать несколько версий одной и той же зависимости одновременно. Это плохо кончится. Если вам действительно нужно (, но старайтесь избегать его как можно больше ), выполните ветвление проекта для каждой версии.
3 - ведение различных проектов
Я бы посоветовал поддерживать каждый репозиторий проектов независимо (с SVN они могли бы быть тем же репо, но в отдельных папках). Ветви и теги должны быть привязаны к одному проекту, а не ко всем. Попробуйте максимально ограничить количество веток, они не решают проблемы (даже с git). Используйте ветки, когда вам нужно поддерживать разные хронологические версии параллельно (, а не варианты ) и сопротивляться столько, сколько вы можете, прежде чем вы действительно это сделаете, каждый выиграет от использования нового кода.
Это позволит наложить ограничения безопасности (не уверен, возможно ли это с ванильным SVN, но есть несколько свободно доступных серверов, которые его поддерживают).
Я бы рекомендовал отправлять уведомления по электронной почте всякий раз, когда кто-то принимает участие в проекте, всем, кто потенциально заинтересован.
4 - Организация дерева исходных текстов проекта
Каждый проект должен иметь следующие структуры SVN:
- транк (текущая версия)
- ветви (старые версии, все еще используемые)
- теги (релизы, используемые для создания веток, не задумываясь, когда требуются патчи)
Когда проект станет больше, организуйте ветки и теги в подпапках (например, ветки / V1.0 / V1.1 и ветки / V2.0 / V2.1).
Иметь корневую папку со следующими подпапками: (некоторые из них могут быть созданы самим VC)
- Система сборки (материал, необходимый для ваших make-файлов или других)
- Инструменты (если есть, например, инструмент XSLT или компилятор SOAP, сценарии для запуска тестов)
- Данные (тестовые данные, которые вам нужны во время работы)
- Вывод (куда система сборки ставит двоичные файлы)
- Temp Output (временные файлы, созданные компиляцией, необязательно)
- 1064 * Зависимость *
- Документы (если есть;) или созданные документы)
- Релизы (сгенерированные архивы см. Позже)
- Пример (небольшой проект, демонстрирующий использование проекта / библиотеки)
- Источник (я не люблю разделять заголовки и .cpp, но это мой путь)
- Избегайте слишком большого количества подпапок, сложно искать деревья, списки проще
- Правильно определите порядок сборки каждой папки (менее необходим для VC, но все же)
- Я делаю мои пространства имен совпадающими с именами папок (старые привычки Java, но работает)
- Четко определите «публичную» часть, которую вам нужно экспортировать
- Если проект достаточно большой, чтобы вместить несколько двоичных файлов / библиотек, каждый должен иметь свою собственную папку
Не передайте любые сгенерированные вами двоичные файлы, только выпуски. Двоичные файлы любят конфликтовать друг с другом и причинять боль другим людям в команде.
5 - Упаковка проектов
Во-первых, обязательно включите текстовый файл с ревизией SVN и датой, есть автоматический способ сделать это с помощью автоматического реквизита.
У вас должен быть скрипт для генерации релизов (если позволяет время). Он проверит, что все зафиксировано, сгенерирует новый номер версии .... Создайте архив zip / tar.gz, который необходимо зафиксировать / заархивировать, имя которого содержит ревизию SVN, ветвь и текущую дату (формат должен быть нормализован по всей проекты). В архиве должно быть все необходимое для запуска приложения / использования библиотеки в файловой структуре. Создайте тег, чтобы вы могли начать с него для экстренного исправления ошибок.