Компоновка SVN — лучшая практика

Question

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

Я прочитал соответствующий SVN QA, но у меня есть собственный вопрос, на который мне нужен ответ.
Я могу сделать:

/trunk
/tags
/branches
/3rdparty

Где все, что мы разрабатываем, исходит из /trunk, а все сторонние приложения, которые мы не меняем, попадают в /3rdparty.

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

Все ли мои базы покрыты?

Answer 1

Красная книга SVN здесь включает много информации о макетах для различных типов проектов и о том, как ими управлять.

Вы также можете использовать перехватчики/триггеры/внешние устройства для получения данных из независимого репозитория под названием «3rd party».Таким образом, когда разработчик получает один репозиторий, он получает и третью часть.Существует множество способов разделить задачи, но представить единое репо из компонентов.

Удачи

Answer 2

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

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

Я бы также разместил репо примерно так:

project
 /trunk
 /branches
 /tags
3rdparty

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

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

Answer 3

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

Я не уверен, стоит ли отмечать то, о чем вы говорите.Вы имеете в виду номер версии?Если это номер версии, передайте его через скрипт и отметьте build.

Answer 4

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

Вам следует рассмотреть возможность использования внешние факторы для сторонних артефактов.

Answer 5

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

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