Во-первых, я знаю об этом: Как бы вы организовали репозиторий Subversion для собственных программных проектов? Далее собственно вопрос: Моя команда реструктурирует наш репозиторий, и я ищу подсказки, как его организовать. (В данном случае SVN). Вот что мы придумали. У нас есть один репозиторий, несколько проектов и несколько перекрестных ссылок svn: externals
\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
\NUnit.v2.4.8
\NCover.v.1.5.8
\<other similar tools>
\commonFiles /*settings strong name keys etc.*/
\ReSharper.settings
\VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
\user1
\user2
\projects
\Solution1 /*Single actual project (Visual Studio Solution)*/
\trunk
\src
\Project1 /*Each sub-project resulting in single .dll or .exe*/
\Project2
\lib
\tools
\tests
\Solution1.sln
\tags
\branches
\Solution2
\trunk
\src
\Project3 /*Each sub-project resulting in single .dll or .exe*/
\Project1 /*Project1 from Solution1 references with svn:externals*/
\lib
\tools
\tests
\Solution2.sln
\tags
\branches
Чтобы очистить словарный запас: Решение означает один продукт, Project - это проект Visual Studio (в результате получается один файл .dll или один .exe).
Вот так планируем выкладывать репозиторий. Основная проблема в том, что у нас есть несколько решений, но мы хотим разделять проекты между решениями. Мы подумали, что на самом деле нет смысла переносить эти общие проекты в их собственные решения, и вместо этого мы решили использовать svn: externals для совместного использования проектов между решениями. Мы также хотим сохранить общий набор инструментов и сторонних библиотек в одном месте в репозитории, и они будут ссылаться на них в каждом Решении с помощью svn: externals.
Что вы думаете об этом макете? Особенно об использовании svn: externals. Это не идеальное решение, но, учитывая все плюсы и минусы, это лучшее, что мы могли придумать. Как бы ВЫ это сделали?
Я считаю, что в Прагматический контроль версий с использованием Subversion есть все необходимое для организации вашего репозитория.
@bal Пожалуйста, не используйте службы сокращения URL-адресов. Это много, лучше сказать "Теперь это 2-е издание: Прагматический контроль версий с использованием Subversion"
Мы настроили наши так, чтобы они почти точно соответствовали тому, что вы опубликовали. Используем общую форму:
\Project1
\Development (for active dev - what you've called "Trunk", containing everything about a project)
\Branches (For older, still-evolving supported branches of the code)
\Version1
\Version1.1
\Version2
\Documentation (For any accompanying documents that aren't version-specific
Хотя я полагаю, что он не такой полный, как ваш пример, он хорошо сработал для нас и позволяет нам держать вещи отдельно. Мне также нравится идея, что у каждого пользователя есть папка «Thrash» - в настоящее время проекты такого типа не попадают в систему управления версиями, и я всегда чувствовал, что они должны это делать.
Я удивлен, что у вас есть отдельный каталог для документов, которые не меняются между версиями ... Я никогда не имел удовольствия работать над таким продуктом! :)
У меня аналогичная планировка, но мой ствол, ветки, метки полностью вверху. Итак: / trunk / main, / trunk / utils, / branch / release / и т. д.
Это оказалось очень удобно, когда мы хотели опробовать другие системы управления версиями, потому что многие инструменты перевода лучше всего работали с базовым макетом SVN из учебника.
Я думаю, что основным недостатком предложенной структуры является то, что общие проекты будут версироваться только с первым решением, к которому они были добавлены (если svn: externals не выглядит более привлекательным, чем я могу себе представить). Например, когда вы создаете ветвь для первого выпуска Solution2, Project1 не будет разветвлен, поскольку он находится в Solution1. Если вам потребуется выполнить сборку из этой ветки позже (выпуск QFE), он будет использовать последнюю версию Project1, а не версию Project1 на момент создания ветки.
По этой причине может быть выгодно поместить общие проекты в одно или несколько общих решений (и, следовательно, каталоги верхнего уровня в вашей структуре), а затем разветвлять их с каждым выпуском решения Любые.
В какой-то мере вы правы. Но мы можем обновить ссылку, если захотим. И помещать общие проекты в их собственное Решение тоже не имеет большого смысла. Хотя я хотел бы найти лучшее решение, чем svn: externals повсюду.
Что вы имеете в виду под «обновить ссылку, если мы хотим»? Я не понимаю, как вы могли бы разветвлять Project1 (что кажется желательным, когда вы разветвляете Solution2) без разветвления Solution1.
Пожалуйста, ознакомьтесь с моим подробным ответом, в частности, чтобы НЕ помещать решения Visual Studio в систему контроля версий.
Почему все это в одном репозитории? Почему бы просто не создать отдельный репозиторий для каждого проекта (я имею в виду «Решение»)?
Ну, по крайней мере, я привык к подходу «один проект на репозиторий». Мне кажется, что структура вашего репозитория слишком сложна.
А сколько проектов вы планируете поместить в один большой репозиторий? 2? 3? 10? 100?
А что вы делаете, когда отменяете разработку одного проекта? Просто удалите его из дерева репозитория, чтобы его было трудно найти в будущем. Или оставить его валяться навсегда? Или когда вы хотите вообще переместить один проект на другой сервер?
А как насчет беспорядка со всеми этими номерами версий? Номера версий одного проекта выглядят как 2, 10, 11, а другого - как 1, 3, 4, 5, 6, 7, 8, 9, 12 ...
Может быть, я глуп, но мне нравится по одному проекту на репозиторий.
1. Один репозиторий - это политика компании, это изменить нельзя. 2. У нас будет около десятка решений. 3. под номерами версий вы подразумеваете ревизии? Для нас это не проблема.
Хорошая структура проекта должна игнорировать остальную часть структуры репозитория, особенно в отношении одного или нескольких репозиториев. Пожалуйста, посмотрите мой подробный ответ.
Обратите внимание, что наличие нескольких репозиториев во многих (большинстве?) Инструментов управления версиями может быть ОЧЕНЬ дорого, например, при реализации безопасности.
Чтобы добавить к проблеме относительного пути:
Не уверен, что это проблема:
Просто проверьте Solution1 / trunk в каталоге с именем «Solution1», то же самое для Solution2: цель «каталогов», фактически представляющих ветки, состоит в том, чтобы не быть видимым был импортирован в рабочую область. Следовательно, возможны относительные пути между «Solution1» (фактически «Solution1 / trunk») и «Solution2» (Solution2 / trunk).
Это очень легко сломается, пожалуйста, посмотрите мой подробный ответ.
RE: относительный путь и проблема с общим файлом -
Кажется, что это специфично для svn, но это не проблема. Еще один человек уже упоминал отдельные репозитории, и это, вероятно, лучшее решение, которое я могу придумать в случае, когда у вас есть разные проекты, относящиеся к произвольным другим проектам. В случае, если у вас нет общих файлов, решение OP (как и многие другие) будет работать нормально.
Мы все еще работаем над этим, и у меня есть 3 разных попытки (разные клиенты), которые я должен решить прямо сейчас, так как я взял на себя настройку несуществующего или плохого контроля версий.
Если проекты ссылаются на другие проекты, это создает кошмар обслуживания, потому что зависимости растут экспоненциально, а ссылки ОЧЕНЬ хрупкие. Пожалуйста, посмотрите мой подробный ответ.
Вы уверены, что имеете в виду "трэш"? А точнее «хлам»?