Схема управления источником

Question

Я разрабатываю множество приложений и имею 3-4 разные библиотеки, которые я повторно использую в этих приложениях (одна для математики, одна для функций базы данных и т. Д.).

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

Все они хранятся в транковом каталоге репозитория subversion, и когда я разветвляю определенные каталоги, я создаю массивную ветвь и т. Д. Поддерживать обратную совместимость довольно сложно, а также просто размер кода сдвига и локальный размер хранилище.

Как лучше всего справляться с этими ситуациями? Как вы размещаете различные проекты?

Вы помещаете каждый проект в свое собственное хранилище Subversion? Или вы используете один репозиторий с несколькими проектами верхнего уровня и стволом / веткой / тегами под ним?

Как вы относитесь к альтернативным проектам? Вы просто компилируете их и ссылаетесь на данные?

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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