Макет SVN-лучшая практика
в CVS у нас есть проект с несколькими каталогами.
Существует ночная сборка, которая должна вытащить материал из другого каталога в том же проекте CVS, чтобы построить ночную сборку. Поэтому я должен иметь это в виду, и мне нужно изменить сценарий сборки, чтобы проверить вещи из разных репозиториев, если мы перейдем к SVN.
Я прочитал связанный SVN QA, но у меня есть свой вопрос, на который мне нужен ответ.
Я могу ... :
/trunk
/tags
/branches
/3rdparty
где все, что мы разрабатываем, выходит из / trunk, и любая 3rdparty, которую мы не меняем, переходит в /3rdparty.
все хорошо, теперь ночной скрипт сборки должен пометить багажник, проверить тег, проверить необходимый материал 3rdparty в правильные каталоги, а затем начать процесс сборки.
Результат сборки (скомпилированный материал) может оставаться на монтировании NFS в течение некоторого периода, поэтому команда интеграции может вернуться на 2 недели и воссоздать проблемы.
Все мои базы прикрыты?
5 ответов
SVN redbook здесь включает в себя много информации о макетах для разных типов проектов и о том, как ими управлять.
вы также можете использовать hooks / triggers / externals для извлечения данных из независимого РЕПО под названием "3rd party". Поэтому, когда разработчик проверяет одно РЕПО, он также получает 3-ю часть. Существует множество способов отделить проблемы, но представить единое РЕПО от компонентных.
удачи
возможно, стоит использовать такой движок сборки, как Гудзон или круиз-контроль. Рабочий процесс немного отличается - меток производится после сборки, но вы можете получить дополнительные модули, которые дают вам некоторый контроль над этим. Дело в том, что вся работа над dev сделана для вас, и вы получаете приличную структуру для своих ночных сборок, и вы получаете хороший веб-интерфейс для контроля и мониторинга всего.
лично я бы поставил некоторые внешние определения на багажник, чтобы вытащить в соответствующие сторонние библиотеки в соответствующие места. Таким образом, при изменении версии сторонней библиотеки вы вносите изменения в trunk и не должны изменять сценарии сборки. Это также означает, что вы можете создавать более старые версии, просто проверяя соответствующий ствол/тег/ветвь. Будьте осторожны - просто сделайте их на багажнике, разбросав их вокруг может привести к убийству.
Я бы также наложил РЕПО примерно так:
project
/trunk
/branches
/tags
3rdparty
просто потому, что это дает вам больше возможностей для добавление топ-уровня в какой-то момент. Это позволяет управлять различными проектами совершенно независимо - и вы все равно можете использовать внешние для ссылки на правильные версии от одной к другой, если есть зависимости-это красиво останавливает изменения в одном проекте, молча ломая/изменяя зависимые проекты.
Это можно сделать с помощью отдельных РЕПО, что нормально, но в этом случае я бы поместил отдельный раздел 3rdparty в отдельное РЕПО из начать.
Почему бы вам не переместить 3-ю партию в багажник? когда каждый вы филиал копия 3rd party переходит в филиал. И, очевидно, вы не будете менять сторонние вещи в branche, потому что ваша ветвь закодирована на основе существующих сторонних вещей.
Я не так уверен в пометке того, о чем вы говорите. Вы имеете в виду номер версии? Если это номер версии, передайте его через скрипт и пометьте сборку.
Если "несколько каталогов" - это отдельные компоненты, которые вы хотите использовать независимо, то вы должны иметь каждый в своем собственном репозитории, чтобы их можно было пометить отдельно. Но если это все один автономный проект (т. е. если вы обычно будете помечать и ветвить все компоненты вместе), то вы, вероятно, можете поместить весь код в один репозиторий.
можно использовать внешние ссылки для сторонних артефактов.
мой скрипт проверяет магистраль, изменяет файлы (настраивает номера версий в AssemblyInfo.CS-файлы и т. д.), затем помечает это. Если вам не нужно каким-либо образом изменять файлы, то сначала было бы хорошо пометить их.
кроме того, ваша установка звучит хорошо для меня по крайней мере.