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

Question

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

во-первых, я знаю об этом: как бы вы организовали репозиторий 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 (который результаты в одном .DLL или один .exe)

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

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

8 108

svn version-control repository projects-and-solutions

8 ответов:

Я считаю, что прагматический контроль версий с помощью 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:внешние красивее, чем я воображал). Например, когда вы создаете ветвь для первого выпуска Solutions 2, Project1 не будет разветвлен, так как он живет в Solutions 1. Если вам нужно построить из этой ветви позже (выпуск QFE), он будет использовать последнюю версию Project1, а не версию Project1 в конце время отделения.

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

0

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

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

0

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

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

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

0

У меня похожий макет, но мой ствол, ветви, теги полностью вверху. Так: /магистральные/главные, /багажник/утилит, /филиалы/выпуска/ и т. д.

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

0

Rob Williams · Accepted Answer · 2008-11-20 22:58:38

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

создать сервер непрерывной интеграции (сборки) без каких-либо средств разработки.

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

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

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

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

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

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

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