Макет системы управления версиями

См. Мои ответы на странице рекомендаций по структуре папок проектов и Как вы организовываете свой репозиторий управления версиями?.

Что касается вашего конкретного вопроса, проблема заключается в управлении зависимостями между проектами. Ответ заключается в их версии - каждый проект, который зависит от другого, должен зависеть ТОЛЬКО от двоичного результата этого проекта (или ближайшего эквивалента, если не скомпилированной программы / библиотеки), и этот результат должен быть версирован в каждой такой ссылке. Конечно, сначала вам нужно убедиться, что каждый проект создает ОДИН и ТОЛЬКО ОДИН двоичный результат (или эквивалент).

За счет зависимости только от двоичного результата другого проекта вы делаете каждый проект автономным и значительно упрощаете его обслуживание, поскольку его «интерфейс сборки» представляет собой один файл. Попадание в исходный код / ​​сборку другого проекта похоже на достижение середины реализации библиотеки = множество проблем.

Создавая версии каждого проекта, вы можете изменять исходный код конкретного проекта от имени другого (нового) проекта, но не влиять на другие старые проекты, которые его использовали. По сути, каждый проект становится ПРОДУКТом. Как и с любым другим продуктом, вы должны управлять его выпусками и совместимостью с другими продуктами.

Мои многоразовые библиотеки разрабатываются в отдельных проектах с отдельными каталогами исходного кода в репозитории (я использую TFS, но он должен быть применим к SVN). Я публикую версии этих библиотек в общем месте - в моем случае это сетевой ресурс, на который имеется ссылка через DFS. При необходимости я добавляю ссылки на опубликованные библиотеки в другие мои проекты. Иногда я использую управление версиями (именованные версии), если обнаруживаю, что по какой-то причине мне нужно поддерживать несколько версий библиотеки. В некотором смысле я отношусь ко всем как к сторонним компонентам и не ссылаюсь на их проекты напрямую.

Я думаю, вам нужно отдельное решение для общих проектов и иметь собственный процесс сборки для них. Я бы связал их как двоичные ссылки в ваших основных проектах. Вы все еще можете отлаживать этот код с помощью Visual Studio, если у вас есть файлы pdb. Я думаю, что это единственный способ масштабирования, иначе у вас останутся эти проблемы.

Можно подумать о том, чтобы поместить все общие библиотеки в одно место, а локальные проекты создать каталог ext для размещения всех общих связанных двоичных файлов. Затем вы можете написать сценарии для проверки обновленных версий и т. Д., Чтобы не возиться с ручными обновлениями.

Я никогда не использовал Subversion, но могу предоставить некоторую информацию за пределами вопроса о репозитории. Мой ответ: это действительно зависит от сценария и компании. Для одного из самых крупных проектов, в котором я участвовал, мы использовали следующую структуру. Этот проект состоял примерно из 20 основных сборок, которые будут использоваться различными приложениями. Мы также использовали TFS.

Мы определили проект Common TFS, который содержал единое главное решение для сборки всех проектов в общем проекте. Когда мы строим, мы публикуем двоичные файлы.

Затем у нас был проект TFS для каждого бизнес-подразделения и их различных приложений (каждый BU мог иметь от 1 до n проектов / приложений). Затем мы настраиваем приложения для втягивания двоичных файлов в свои собственные проекты, используя ссылку на файл. В этом случае бизнес-подразделения рассматривали общие библиотеки как сторонние продукты.

В менее формальных ситуациях бизнес-единицы будут напрямую ссылаться на выходные данные сборки (они будут возвращены в систему управления версиями). Это позволило бизнес-подразделению получить новую версию после того, как они были скомпилированы, но, как вы указали, возникают проблемы совместимости. Вот где помогает их полная изоляция.