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

\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

Ответ 1 · рейтинг 92 · Rob Williams

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

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

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

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

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

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

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

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

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). В противном случае вы в конечном итоге столкнетесь с ошибкой, и ваша первая БОЛЬШАЯ проблема будет заключаться в том, чтобы отследить, какие версии ваших различных компонентов задействованы. Просто лучше решить эту проблему заранее.

\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