Как организовать репозиторий управления версиями?

во-первых, я знаю об этом: Как бы вы организовали репозиторий Subversion для проектов программного обеспечения в доме? Далее, собственно вопрос: Моя команда реструктурирует наш репозиторий, и я ищу подсказки о том, как его организовать. (SVN в этом случае). Вот что мы придумали. У нас есть один репозиторий, несколько проектов и несколько svn: внешние перекрестные ссылки

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

чтобы очистить словарь: решение означает один продукт, проект является Visual Studio Project (это приводит к одному .dll или одиночный .exe)

вот как мы планируем выложить репозиторий. Главная проблема в том, что у нас есть несколько решений, но мы хотим делиться проектами между решениями. Мы думали, что нет смысла перемещать эти общие проекты в их собственные решения, и вместо этого мы решили использовать svn:externals для обмена проектами между решениями. Мы также хотим сохранить общий набор инструментов и сторонних библиотек в одном месте в репозитории, и они ссылайтесь на них в каждом решении с помощью svn: externals.

что вы думаете об этой схеме? Особенно об использовании svn: externals. Это не идеальное решение, но, учитывая все плюсы и минусы, это лучшее, что мы могли придумать. Как бы вы это сделали?

108
projects-and-solutions repository svn version-control

8 ответов

если вы будете следовать моим рекомендациям ниже (у меня есть в течение многих лет), вы сможете:

-- поместите каждый проект в любом месте системы управления версиями, пока вы сохраняете структуру из корневого каталога проекта на

-- построьте каждый проект везде на любой машине, с минимальным риском и минимальной подготовкой

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

-- строить и работать с любой комбинацией проектов, так как они являются независимая

-- build и работа с несколькими копиями / версиями одного проекта, так как они независимы

-- избегайте загромождения репозитория управления версиями сгенерированными файлами или библиотеками

рекомендую (вот говядина):

  1. определите каждый проект для получения одного основного результата, такого как an .файл DLL, .EXE, или .JAR (по умолчанию в Visual Studio).

  2. структурируйте каждый проект как дерево каталогов с одним корнем.

  3. создайте автоматический сценарий сборки для каждого проекта в его корневом каталоге, который будет создавать его с нуля, без зависимостей от IDE (но не препятствуйте его созданию в IDE, если это возможно).

  4. рассмотрим NAnt для .NET-проектов в Windows или что-то подобное на основе вашей ОС, платформа цели, etc.

  5. Сделайте каждый сценарий сборки проекта ссылкой на его внешние (сторонние) зависимости из одного локального общего каталога "библиотеки", причем каждый такой двоичный файл полностью идентифицируется версией: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll.

  6. сделать каждый сценарий сборки проекта опубликовать основной результат в одном локальном общем каталоге" выход":%DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe.

  7. сделать каждый сценарий сборки проекта ссылка на его зависимости через настраиваемые и полностью версионные абсолютные пути (см. выше) в каталогах "библиотека" и "выход", и нигде больше.

  8. никогда не позволяйте проекту напрямую ссылаться на другой проект или любое его содержимое-разрешайте ссылки только на основные результаты в каталоге "output" (см. выше).

  9. Сделайте каждый сценарий сборки проекта ссылкой на необходимые инструменты сборки настраиваемым и полностью версионным абсолютный путь: %DirToolRoot%\ToolA.2.3.4, %DirToolRoot%\ToolB.6.7.8.

  10. сделать каждый проект сборки исходного содержимого сценария ссылки абсолютным путем относительно корневого каталога проекта:${project.base.dir}/src, ${project.base.dir}/tst (синтаксис зависит от инструмента построения).

  11. всегда требуется сценарий сборки проекта для ссылки на каждый файл или каталог через абсолютный, настраиваемый путь (коренится в каталоге, указанном настраиваемой переменной):${project.base.dir}/some/dirs или ${env.Variable}/other/dir.

  12. никогда не позволяйте сценарию сборки проекта ссылаться на что-либо с относительным путем, таким как .\some\dirs\here или ..\some\more\dirs всегда используйте абсолютные пути.

  13. никогда не позволяйте сценарию сборки проекта ссылаться на что-либо, используя абсолютный путь, который не имеет настраиваемого корневого каталога, например C:\some\dirs\here или \server\share\more\stuff\there.

  14. для каждого настраиваемого корневого каталога, на который ссылается сценарий сборки проекта, определите переменная среды, которая будет использоваться для этих ссылок.

  15. попытайтесь минимизировать количество переменных среды, которые необходимо создать для настройки каждой машины.

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

  17. не кладите машин-специфическую раковину конфигурации сценарий в систему управления версиями; вместо этого для каждого проекта зафиксируйте копию сценария в корневом каталоге проекта в качестве шаблона.

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

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

  20. устоять перед искушением совершить какое-либо созданных файлов в системе управления исходным кодом-нет проекта, нет сформированного источника, не создаются документы.

  21. если вы используете IDE, сгенерируйте все файлы управления проектами и не фиксируйте их в системе управления версиями (включая файлы проектов Visual Studio).

  22. установить сервер с официальная копия всех внешних библиотек и инструментов, которые будут скопированы/установлены на рабочих станциях разработчиков и машинах сборки. Создайте резервную копию вместе с репозиторием управления версиями.

  23. установите сервер непрерывной интеграции (build machine) без каких-либо инструментов разработки.

  24. рассмотрим инструмент для управления внешними библиотеками и результатами, такими как Ivy (используется с Ant).

  25. не использовать Maven-это сначала сделает вас счастливыми, а потом заставит вас плакать.

обратите внимание, что ничто из этого не относится к Subversion, и большинство из них являются общими для проектов, предназначенных для любой ОС, оборудования, платформы, языка и т. д. Я использовал немного синтаксиса для ОС и инструментов, но только для иллюстрации-я надеюсь, что вы переведете на свою ОС или инструмент по выбору.

дополнительное Примечание относительно решений Visual Studio: не помещайте их в систему управления версиями! При таком подходе они вообще не нужны или их можно создать (как и файлы проекта Visual Studio). Тем не менее, я считаю, что лучше оставить файлы решений отдельным разработчикам для создания/использования по своему усмотрению (но не регистрироваться в системе управления версиями). Я держу Rob.sln файл на моей рабочей станции, из которого я ссылаюсь на мой текущий проект(ы). Поскольку все мои проекты автономны, я могу добавлять / удалять проекты по желанию (это означает отсутствие зависимости от проекта ссылки на литературу.)

пожалуйста, не используйте Subversion externals (или аналогичные в других инструментах), они являются анти-шаблоном и, следовательно, ненужными.

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

@VonC: вы не хотите работать все время с "ant.банка " вместо "ant-a.b.c.d.jar" после того, как вы обжигаетесь, когда ваш сценарий сборки ломается, потому что вы неосознанно запустили его с несовместимой версией Ant. Это особенно распространено между Ant 1.6.5 и 1.7.0. Обобщая, вы всегда хотите знать, какая конкретная версия каждого компонента используется, включая вашу платформу (Java A. B. C. D) и ваш инструмент сборки (Ant E. F. G. H). В противном случае, вы в конечном итоге столкнитесь с ошибкой, и ваша первая большая проблема будет отслеживать, какие версии ваших различных компонентов участвуют. Просто лучше решить эту проблему заранее.

93

Я считаю, что прагматический контроль версий с помощью Subversion имеет все необходимое для организации вашего репозитория.

3

мы настроили наши, чтобы почти точно соответствовать тому, что вы опубликовали. Используем общую форму:

\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

хотя я полагаю, что не так полно, как ваш пример, он хорошо работал для нас и позволяет нам держать вещи отдельно. Мне нравится идея, что у каждого пользователя есть папка "трэш" - в настоящее время эти типы проектов не заканчиваются в системе управления версиями, и я всегда чувствовал, что они должны.

3

Почему все это в одном репозитории? Почему бы просто не иметь отдельный репозиторий для каждого проекта (я имею в виду "решение")?

ну, по крайней мере, я использовал подход "один проект на репозиторий". Ваша структура хранилища кажется мне слишком сложной.

и сколько проектов вы планируете поместить в этот один большой репозиторий? 2? 3? 10? 100?

а что вы делаете, когда отменяете разработку одного проекта? Просто удалите его из дерева репозитория, чтобы он будет трудно найти в будущем. Или оставить его навсегда? Или когда вы хотите переместить один проект на другой сервер в целом?

а как насчет беспорядка всех этих номеров версий? Номера версий одного проекта, как 2, 10, 11, а другая идет как 1, 3, 4, 5, 6, 7, 8, 9, 12...

может быть, я глуп, но мне нравится один проект на репозиторий.

1

Я думаю, что основным недостатком предлагаемой конструкции является то, что общие проекты будут версионными с первым решением они были добавлены (если в SVN:внешние красивее, чем я воображал). Например, когда вы создаете ветвь для первого выпуска решения 2, Project1 не будет ветвиться, так как он живет в решении 1. Если вам нужно построить из этой ветви позже (выпуск QFE), он будет использовать последнюю версию Project1, а не версию Project1 в время филиала.

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

0

чтобы добавить к проблеме относительного пути:

Я не уверен, что это проблема:
Просто checkout Solution1 / trunk в каталоге с именем "Solution1", то же самое для решения 2: цель "каталогов", фактически представляющих ветви, -не видно когда импортировать в рабочую область. Следовательно, возможны относительные пути между "Решением1" (фактически "Решением1/магистралью") и "Решением2" (Решением2/магистралью).

0

RE: относительный путь и проблема с общим файлом -

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

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

0

У меня похожий макет, но мой ствол, ветви, теги полностью вверху. Итак: / trunk / main, / trunk / utils, / branches / release / и т. д.

Это оказалось очень удобно, когда мы хотели попробовать другие системы управления версиями, потому что многие из инструментов перевода лучше всего работали с базовым макетом учебника SVN.

0