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

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

Можно ли это сделать в SVN? Я провел немного исследований, и до сих пор похоже, что такого рода вещи не поддерживаются.

Изменить

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

Edit2

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

Ответ 1

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

Для этого сделайте ветку с внешней стороны на ранней стадии, назвав ее "Release". Затем работайте на багажнике как обычно, когда вы будете готовы к выпуску, объедините свои изменения с багажника на "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>

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

Ответ 12

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

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

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

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

Ответ 13

FYI,

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