Верстка SVN - лучшая практика - PullRequest
6 голосов
/ 17 июля 2009

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

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

/trunk
/tags
/branches
/3rdparty

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

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

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

Ответы [ 5 ]

9 голосов
/ 17 июля 2009

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

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

Удачи

2 голосов
/ 21 июля 2009

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

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

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

project
 /trunk
 /branches
 /tags
3rdparty

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

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

1 голос
/ 18 июля 2009

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

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

1 голос
/ 17 июля 2009

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

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

0 голосов
/ 17 июля 2009

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

Кроме этого, твоя установка звучит хорошо для меня, по крайней мере.

...