SVN layout - лучшая практика

Question

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

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

/trunk 
/tags 
/branches 
/3rdparty 

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

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

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

Answer 1

SVN redbook here содержит много информации о макетах для разных типов проектов и способах их управления.

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

Успехов

Answer 2

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

Помимо этого, ваша установка звучит для меня как минимум.

Answer 3

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

Я не уверен в том, что помечаю то, о чем вы говорите. Это номер версии, которую вы имеете в виду? Если это номер версии, пройдите через сценарий и назовите сборку.

Answer 4

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

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

Answer 5

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

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

Я также слой репо-то вроде:

project 
/trunk 
/branches 
/tags 
3rdparty 

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

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