Управление релизами в SVN

нет как таковой. Принятый способ сделать релизы в SVN-иметь каталог" теги", в котором ваш источник релиза копируется для каждого конкретного выпуска. Например /tags/release-0.11 ... Там нет ничего, что мешает вам возиться с tags каталог случайно, из коробки, но некоторые люди любят настраивать крючки предварительной фиксации, чтобы предотвратить случайные фиксации для выпуска тегов.

здесь приличные статьи описание процесса выпуска в SVN.

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

вы исследовали график пересмотра Tortoise SVN? Если вы помечаете каждый выпуск (который, как указывали другие, не включает копирование файлов ни на сервере, ни на рабочей станции), то вы можете увидеть все изменения в хронологическом порядке с тегами, указывающими на фактические выпуск. Вы можете различать выпуски и / или магистраль, выделив две интересующие вас версии и выбрав diff в контекстном меню.

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

Это, по сути, конкретная обычная реализация ветвления в svn. Взгляните на онлайн СВН книга для более подробной информации.

маркер будет сообщением фиксации, написанным при создании тега для выпуска (копия svn в /tags). По крайней мере, это наиболее распространенный метод.

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

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

Я думаю, что обычно лучше держать эти два инструмента отдельно. Хотя волей-неволей, в частности, пытается связать их вместе, они делают это только просто. Есть некоторые вещи, такие как электронная почта пользователей изменений к вопросам, добавление комментариев к вопросам, добавление вложений к вопросам, которые гораздо лучше сделать в специализированной части программного обеспечения, как Jira. С другой стороны, Jira не очень хороша в управлении версиями, источник слияния и ветвления ... который лучше обрабатывается в специализированном программном обеспечении, таком как Subversion.

для полного раскрытия есть другие инструменты, кроме Jira, такие как Bugzilla, Trac, IBM Rational Jazz и т. д. это может сделать то же самое с Subversion, что и Jira, хотя и с различными уровнями функциональности.

взгляните на темы книги SVN:

Теги и просмотр репозитория

теги и ветви - "копировать при записи", что означает, что в репозитории нет дополнительных копий. Как правило, индивидуальный разработчик не должен иметь локальную копию, если он не нуждается в ней по какой-либо причине (т. е. разработка на ветке).

Если вы помечаете каждый выпуск, вы можете увидеть теги, просмотрев репозиторий. Ссылки выше говорят непосредственно об инструментах командной строки, но есть также инструменты GUI, такие как TortoiseSVN в Windows. Вы можете получить историю, сделать сравнения и т. д.

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

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

+1 для использования сообщения фиксации.

для проекта я создал пользователя SVN под названием build. Машина сборки использовала этот логин для SVN. Если строить машину/Процесс сборки, он также обновил файл и SVN фиксировать сообщение версия/другой идентификатор сборки.

затем мы создали тег для этой сборки. Таким образом, в багажнике мы могли видеть сборки, когда/где они перемежаются с другими изменениями.

Так что мой предложение (самый простой способ сделать это) - создать другие файлы под названием build (или что-то еще, что вы хотите) и добавить к этому или просто изменить его в своем сценарии/процессе сборки, а затем вернуть его в/зафиксировать его с именем версии выпуска в качестве сообщения фиксации. Простой. Затем он появится в ваших запросах истории.

кроме того, если вы знаете, какие ревизии вы сравниваете, вы можете сделать SVN diff, и вы увидите, какие файлы изменились и как между двумя ревизиями.

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

кроме того, мы обычно настраиваем три каталога в каждом репозитории. Ветви, ствол и бирки. Как кто-то отметил, Теги используются специально для идентификации выпуска.

Я сталкиваюсь с той же проблемой, и то, как я пытался исправить это для моей компании, - это иметь папку "release" в багажнике, эта папка содержит только фактический исполняемый файл или то, что должно быть частью развертывания.

Я создаю новую папку для каждого выпуска, начиная с "1.0.0.0" в папке "release", а также помечаю код тем же именем папки выпуска i.e 1.0.0.0 в данном случае.

Я не уверен, что это правильный способ сделать это, но это решает мою проблему, чтобы узнать исполняемый файл, который я развернул.

Если вы следуете обычному соглашению svn "теги / ветви / магистраль" в корне вашего репозитория, разработчики обычно не хотят проверять весь репозиторий, только из магистрали вниз.

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

мы используем утилиту под названием SubWCRev, которая поставляется с Tortoise SVN. У нас есть событие после сборки, которое захватывает номер версии SVN и вставляет его в файл - в случае веб-сайтов мы помещаем это в файл под названием version.формат html. Затем в любой момент времени вы можете связать свой релиз (будь то релиз в настоящее время QA, Prod или любая другая среда) до точного номера редакции в SVN. Больше нет тегов, больше не интересно, что включено в релиз, больше не прослушивание разработчиков для обновления файла версии.

чтобы определить, что было включено в выпуск, вы можете просто вытащить журналы SVN из редакции X в редакцию Y и скопировать комментарии в документ и отредактировать, чтобы сделать довольно заметки о выпуске doc. То же самое верно для обзора кода или изменения выпусков; просто используйте номера версий привязаны к вашей версии.html, свойства.cs, readme.txt, etc.

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

кстати,

SVN copy не является печатной копией, это просто ссылка, поэтому не займет места, кроме измененных файлов. И эти версии все равно займут место. Таким образом, создание копии для каждого выпуска не займет никакого места.