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

Question

Когда я смотрю в журнале SVN, мне очень хочется увидеть маркеры, которые сообщают мне, когда были сделаны релизы. Я видел это в других системах контроля версий, таких как PVCS и Perforce .

Можно ли это сделать в SVN? Я провел небольшое исследование, и похоже, что подобные вещи не поддерживаются.

Редактировать

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

Edit2

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

Answer 1

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

Вот достойная статья , описывающая процесс выпуска в SVN.

Answer 2

Ричард, теги очень близки, но мне интересно, может быть, вам не нужна отдельная ветка релиза.

Для этого сделайте ветку из ствола на ранней стадии, которая называется что-то вроде 'Release'. Затем работайте с транком в обычном режиме, когда вы будете готовы к выпуску, объедините ваши изменения из транка в выпуск. Это единственный способ изменить релиз.

Затем вы можете пометить тегом релиз, если хотите, но не на 100%.

Но это даст вам ветку с подмножеством ревизий ствола. Узнайте ваши даты выхода с:

svn log --stop-on-copy svn://server/project/branches/release

Это даст вам список дат выпуска (с изменениями). Чтобы увидеть, что в каждом выпуске сделайте:

svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

Хотя Subversion сама по себе не обеспечивает управление выпусками, инструментам управления версиями обычно не поручается эта операция. Что вам нужно, так это инструмент управления действиями / проблемами / изменениями, который может взаимодействовать с Subversion.

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

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

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

Answer 7

+ 1 за использование сообщения коммита.

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

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

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

Answer 8

Взгляните на темы SVN Book:

Метки а также Просмотр репозитория

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

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

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

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

Answer 9

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

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

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

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

Answer 10

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