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

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

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

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

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

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

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

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

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

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

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

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

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

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. Сделайте так, чтобы каждый сценарий сборки проекта ссылался на свои зависимости через настраиваемые абсолютные пути с полной версией (см. Выше) в каталогах «library» и «output», И НЕТ ГДЕ ДРУГОЕ.

8. НИКОГДА не позволяйте проекту напрямую ссылаться на другой проект или какое-либо его содержимое - разрешайте ссылки только на основные результаты в «выходном» каталоге (см. Выше).

9. Сделайте так, чтобы каждый скрипт сборки проекта ссылался на необходимые инструменты сборки по настраиваемому абсолютному пути с полной версией: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.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. Установите сервер непрерывной интеграции (машину сборки) без каких-либо инструментов разработки.

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

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

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

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

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

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

@VonC: вы НЕ хотите постоянно работать с «ant.jar», а не с «ant-a.b.c.d.jar» после того, как вы обожжетесь, когда ваш сценарий сборки сломается, потому что вы неосознанно запустили его с несовместимой версией Ant. Это особенно характерно для Ant 1.6.5 и 1.7.0. Обобщая, вы ВСЕГДА хотите знать, какая конкретная версия КАЖДОГО компонента используется, включая вашу платформу (Java A.B.C.D) и ваш инструмент сборки (Ant E.F.G.H). В противном случае вы в конечном итоге столкнетесь с ошибкой, и ваша первая БОЛЬШАЯ проблема будет заключаться в том, чтобы отследить, какие версии ваших различных компонентов задействованы. Просто лучше решить эту проблему заранее.

Я считаю, что в Pragmatic Version Control с использованием 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» - в настоящее время проекты такого типа не попадают в систему управления версиями, и я всегда чувствовал, что должны.

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

Ну, по крайней мере, я привык к подходу «один проект на репозиторий». Мне кажется, что структура вашего репозитория слишком сложна.

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

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

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

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

Я думаю, что основным недостатком предложенной структуры является то, что общие проекты будут версироваться только с первым решением, к которому они были добавлены (если svn: externals не выглядит более привлекательным, чем я могу себе представить). Например, когда вы создаете ветвь для первого выпуска Solution2, Project1 не будет разветвлен, поскольку он находится в Solution1. Если вам потребуется выполнить сборку из этой ветки позже (выпуск QFE), он будет использовать последнюю версию Project1, а не версию Project1 на момент создания ветки.

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

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

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

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

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

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

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

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