Как Вы организуете свой репозиторий управления версиями?
8 ответов
Если Вы следуете моим рекомендациям ниже (я имею в течение многих лет), Вы будете в состоянии:
- помещает каждый проект где угодно в управление исходным кодом, пока Вы сохраняете структуру от корневого каталога проекта на вниз
- разрабатывают каждый проект где угодно на любой машине, с минимальным риском и минимальной подготовкой
- разрабатывают каждый абсолютно автономный проект, пока у Вас есть доступ к его двоичным зависимостям (локальная "библиотека", и "произведите" каталоги)
- сборка и работа с любой комбинацией проектов, так как они независимы
- сборка и работа с несколькими копиями/версиями единственного проекта, так как они независимы
- стараются не создавать помехи Вашему репозиторию управления исходным кодом сгенерированными файлами или библиотеками
, я рекомендую (вот говядина):
-
Определяют каждый проект произвести единственный основной поставляемый компонент, такой как.DLL.EXE, или.JAR (значение по умолчанию с Visual Studio).
-
Структура каждый проект как дерево каталогов с единственным корнем.
-
Создают автоматизированный сценарий сборки для каждого проекта в его корневом каталоге, который создаст его с нуля без зависимостей от IDE (но не препятствуйте тому, чтобы он был создан в IDE, если выполнимый).
-
Рассматривают nAnt для проектов.NET в Windows, или что-то подобное на основе Вашей ОС, целевой платформы, и т.д.
-
Делает каждую ссылку сценария сборки проекта его внешние (сторонние) зависимости из единственного локального общего каталога "библиотеки" с каждым таким двоичным файлом, ПОЛНОСТЬЮ определенным версией:
%DirLibraryRoot%\ComponentA-1.2.3.4.dll,%DirLibraryRoot%\ComponentB-5.6.7.8.dll. -
Заставляют каждый сценарий сборки проекта опубликовать основной поставляемый компонент к единственному локальному общему "выходному" каталогу:
%DirOutputRoot%\ProjectA-9.10.11.12.dll,%DirOutputRoot%\ProjectB-13.14.15.16.exe. -
Делают каждую ссылку сценария сборки проекта его зависимости через настраиваемые и полностью имеющие версию полные пути (см. выше) в "библиотеке" и ЕЩЕ "производят" каталоги, И НЕ ГДЕ.
-
НИКОГДА не позволяют проекту, непосредственно ссылочному, другой проект или любое его содержание - только позволяют ссылки на основные результаты в "выходном" каталоге (см. выше).
-
Делают каждую ссылку сценария сборки проекта его необходимые инструменты сборки настраиваемым и полностью имеющим версию полным путем:
%DirToolRoot%\ToolA\1.2.3.4,%DirToolRoot%\ToolB\5.6.7.8. -
Делают каждое содержание опорного источника сценария сборки проекта полным путем относительно корневого каталога проекта:
${project.base.dir}/src,${project.base.dir}/tst(синтаксис варьируется инструментом сборки). -
ВСЕГДА требуют, чтобы сценарий сборки проекта сослался на КАЖДЫЙ файл или каталог через абсолютный, настраиваемый путь (базировался в каталоге, определенном настраиваемой переменной):
${project.base.dir}/some/dirsили${env.Variable}/other/dir. -
НИКОГДА не позволяют сценарию сборки проекта ссылаться на ЧТО-ЛИБО с относительным путем как [1 110] или
..\some\more\dirs, ВСЕГДА использовать полные пути. -
НИКОГДА не позволяют сценарию сборки проекта ссылаться на ЧТО-ЛИБО с помощью полного пути, который не имеет настраиваемого корневого каталога, как [1 112] или
\\server\share\more\stuff\there. -
Для каждого настраиваемого корневого каталога, на который ссылается сценарий сборки проекта, определите переменную среды, которая будет использоваться для тех ссылок.
-
Попытка минимизировать количество переменных среды необходимо создать для конфигурирования каждой машины.
-
На каждой машине, создайте сценарий оболочки, который определяет необходимые переменные среды, который характерен для ТОЙ машины (и возможно характерен для того пользователя, при необходимости).
-
НЕ помещают определенный для машины сценарий оболочки конфигурации в управление исходным кодом; вместо этого, для каждого проекта фиксируйте копию сценария в корневом каталоге проекта как шаблон.
-
ТРЕБУЮТ, чтобы каждый сценарий сборки проекта проверил каждую из своих переменных среды и аварийное прекращение работы со значимым сообщением, если они не определяются.
-
ТРЕБУЮТ, чтобы каждый сценарий сборки проекта проверил каждый из своих зависимых исполняемых файлов инструмента сборки, внешних файлов библиотеки, и зависимых поставляемых файлов проекта и аварийного прекращения работы со значимым сообщением, если те файлы не существуют.
-
СОПРОТИВЛЯЮТСЯ искушению фиксировать ЛЮБЫЕ сгенерированные файлы в управление исходным кодом - никакие результаты проекта, никакой сгенерированный источник, никакие сгенерированные документы, и т.д.
-
, Если Вы используете IDE, генерируете любые файлы управления проекта, Вы можете, и не передавать их управлению исходным кодом (это включает файлы проекта Visual Studio).
-
Устанавливают сервер с официальной копией всех внешних библиотек и инструментов, чтобы копироваться/устанавливаться на рабочих станциях разработчика и машинах сборки. Создайте резервную копию его, наряду с Вашим репозиторием управления исходным кодом.
-
Устанавливают непрерывный сервер интеграции (машина сборки) без средств разработки вообще.
-
Считают инструмент для управления Вашими внешними библиотеками и результатами, такими как Ivy (используемым с Муравьем).
-
НЕ используют Знатока - это первоначально сделает Вас счастливыми, и в конечном счете заставит Вас кричать.
Примечание, что ни одно из этого не характерно для Подрывной деятельности и большей части из нее, универсально к проектам, предназначенным к любой ОС, аппаратным средствам, платформе, языку, и т.д. Я действительно использовал немного ОС - и определенный для инструмента синтаксис, но только для иллюстрации - я полагаю, что Вы переведете в свою ОС или предпочтительный инструмент.
Дополнительное примечание относительно решений для Visual Studio: не помещайте их в управление исходным кодом! С этим подходом Вам не нужны они вообще, или можно генерировать их (точно так же, как файлы проекта Visual Studio). Однако я нахожу, что он лучше всего оставляет файлы решения отдельным разработчикам для создавания/использования, поскольку они считают целесообразным (но не зарегистрированные к управлению исходным кодом). Я сохраняю Rob.sln файл на моей рабочей станции, от которой я ссылаюсь на свой текущий проект (проекты). Начиная с моих проектов все автономные, я могу добавить/удалить проекты по желанию (который не означает основанных на проекте ссылок зависимостей).
не используйте внешний облик Подрывной деятельности (или подобный в других инструментах), они - антишаблон и, поэтому, ненужный.
при реализации непрерывной интеграции, или даже когда Вы просто хотите автоматизировать процесс выпуска, создайте сценарий для него. Сделайте единственный сценарий оболочки что: берет параметры названия проекта (как перечислено в репозитории) и имя тега, создает временный каталог в настраиваемом корневом каталоге, проверяет источник для данного названия проекта и имени тега (путем построения соответствующего URL в случае Подрывной деятельности) к тому временному каталогу, выполняет чистую сборку, которая запускает тесты и упаковывает поставляемый компонент. Этот сценарий оболочки должен работать над любым проектом и должен быть проверен в управление исходным кодом, поскольку часть Ваш "разрабатывает инструменты" проект. Ваш непрерывный сервер интеграции может использовать этот сценарий в качестве своей основы для строительных проектов, или это могло бы даже обеспечить его (но Вы все еще могли бы хотеть свое собственное).
@VonC: Вы НЕ хотите работать в любом случае с "ant.jar", а не "муравьем-a.b.c.d.jar" после того, как Вы записываетесь, когда Ваш сценарий сборки повреждается, потому что Вы невольно выполнили его с несовместимой версией Муравья. Это особенно распространено между Муравьем 1.6.5 и 1.7.0. При обобщении Вы ВСЕГДА хотите знать, какая определенная версия КАЖДОГО компонента используется, включая Вашу платформу (Java A.B.C.D) и Ваш инструмент сборки (Муравей 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
, В то время как я предполагаю не столь завершенный как Ваш пример, он работал хорошо на нас и позволяет нам разделить вещи. Мне нравится идея каждого пользователя, имеющего папку "Thrash" также - в настоящее время, те типы проектов не заканчиваются в Управлении исходным кодом, и я всегда чувствовал, что они должны.
Почему все это имеет в одном репозитории? Почему не только имеют отдельный репозиторий для каждого проекта (я имею в виду "Решение")?
ну, по крайней мере, я привык для one-project-per-repository-approach. Ваша структура репозитория кажется сверхсложной мне.
И сколько проекта Вы планируете поместить в этот большой репозиторий? 2? 3? 10? 100?
И что Вы делаете при отмене разработки одного проекта? Просто удалите его из дерева репозитория так, чтобы стало трудно найти в будущем. Или оставьте его лежащий вокруг навсегда? Или когда Вы хотите переместить один проект в другой сервер в целом?
И что относительно путаницы всех тех номеров версий? Номера версий одного проекта, идущего как 2, 10, 11, в то время как другие движения как 1, 3, 4, 5, 6, 7, 8, 9, 12...
, Возможно, я глуп, но мне нравится один проект на репозиторий.
Я думаю, что основной недостаток предложенной структуры - то, что общие проекты только будут имеющими версию с первым решением, они были добавлены к (если svn:externals не более необычен, чем я воображаю). Например, при создании ответвления для первого выпуска Solution2 Project1 не перейдется, так как это живет в Solution1. Если необходимо создать из того ответвления в более позднее время (выпуск QFE), это будет использовать последнюю версию Project1, а не версию Project1 во время ответвления.
поэтому может быть выгодно поместить общие проекты в одно или несколько общих решений (и таким образом каталоги верхнего уровня в Вашей структуре) и затем перейти их с каждым выпуском любой решение.
РЕ: проблема относительного пути и совместно используемого файла -
кажется, что это svn конкретный, но это не проблема. Еще один человек уже упомянул отдельные репозитории, и это - вероятно, лучшее решение, о котором я могу думать в случае, где у Вас есть различные проекты, обращающиеся к произвольным другим проектам. В случае, где у Вас нет совместно используемых файлов тогда, будет хорошо работать решение OP (А также многие другие).
Мы все еще разрабатываем это, и у меня есть 3 различных усилия (различные клиенты), что я должен решить прямо сейчас, так как я принял установку или несуществующее или плохое управление версиями.
Добавить к проблеме относительного пути:
я не уверен, что это - проблема:
Просто контроль Solution1/trunk в соответствии с каталогом по имени "Solution1", так же для Solution2: цель 'каталогов', на самом деле представляющих ответвления, к не быть видима когда-то импортированный в рабочую область. Следовательно относительные пути возможны между 'Solution1' (на самом деле 'Solution1/trunk') и 'Solution2' (Solution2/trunk).
У меня есть подобное расположение, но моя соединительная линия, ответвления, теги полностью наверху. Так:/trunk/main,/trunk/utils,/branches/release/, и т.д.
Это закончило тем, что было действительно удобно, когда мы хотели испытать другие системы управления версиями, потому что многие инструментальные средства для перевода работали лучше всего с основным учебником расположение SVN.