Управление релизами в SVN
https://stackoverflow.com/questions/569353
-
05-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Когда я смотрю в журнал SVN, мне действительно жаль, что я не могу увидеть маркеры, которые сообщают мне, когда были сделаны релизы.Я видел это в других системах контроля версий, таких как PVCS и Волей - неволей.
Можно ли это сделать в SVN?Я провел небольшое исследование, и пока, похоже, подобные вещи не поддерживаются.
Редактировать
Мы не хотим копировать наш исходный код в другую папку для каждого выпуска.Это приводит к огромному количеству ненужного дублирования файлов на компьютере разработчиков и предоставляет нам только запись номера редакции каждого выпуска.Я могу сделать это с помощью текстового документа!
Редактировать 2
Моя цель - иметь единый вид, который показывает мне хронологию моих выпусков, между которыми я могу видеть все изменения кода, произошедшие между каждым выпуском.Это упрощает компиляцию примечаний к выпуску.
Решение
Ричард, теги очень близки, но я задаюсь вопросом, не может ли то, что вам нужно, быть выделенной веткой выпуска.
Для этого создайте ответвление от trunk на ранней стадии, называемое чем-то вроде 'Release'.Затем работайте с trunk в обычном режиме, когда будете готовы к выпуску, объедините свои изменения из trunk в "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>
Также обратите внимание, что, работая таким образом, вы не ограничены строго последовательным выпуском всего, что находится в trunk - вы можете выбирать версии по своему усмотрению, исключая версии, если вы пока не хотите их выпускать, но все равно включая последующие версии.
Другие советы
Не как таковой.Общепринятый способ создания релизов в SVN - это иметь каталог "tags", куда копируется исходный код вашего выпуска для каждого конкретного выпуска.Например /tags/release-0.11 ...Нет ничего, что мешало бы вам возиться с tags каталог случайно, из коробки, но некоторым людям нравится настраивать перехваты предварительной фиксации, чтобы предотвратить случайные фиксации для освобождения тегов.
Вот такой приличная статья описание процесса выпуска в SVN.
Моя цель - иметь единый вид, который показывает мне хронологию моих выпусков, между которыми я могу видеть все изменения кода, которые произошли между каждым выпуском.
Вы исследовали график ревизий Tortoise SVN?Если вы пометите каждый выпуск (что, как указывали другие, не предполагает копирования файлов ни на сервер, ни на рабочую станцию), то вы сможете увидеть все редакции в хронологическом порядке, с тегами, указывающими на фактические выпуски.Вы можете проводить различие между выпусками и / или магистралью, выделив две интересующие вас редакции и выбрав diff из контекстного меню.
Копирование магистрали в путь к тегам в репозитории svn - это способ добиться этого.Это копия 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:
Теги и ветви "копируются при записи", что означает, что в репозитории нет дополнительных копий.Как правило, отдельному разработчику не нужно иметь локальную копию, если только она не нужна ему по какой-либо причине (Т.е.разрабатываемый на ветке).
Если вы пометите каждый выпуск тегом, то сможете увидеть теги, просмотрев репозиторий.Приведенные выше ссылки говорят непосредственно об инструментах командной строки, но в Windows есть также инструменты с графическим интерфейсом, такие как TortoiseSVN.Вы можете получить историю, провести сравнения и т.д.
Чтобы увидеть изменения, внесенные в релиз, вам просто нужно показать журнал магистрали от редакции тега, который вы хотите вернуть, до редакции предыдущего тега + 1.Это звучит как дополнительная работа, но это довольно просто, как только вы к этому привыкнете.
С помощью наших инструментов сборки мы также передаем файл с некоторой информацией о номере версии обратно в магистраль, а в комментарии указывается номер версии сборки.Если ваш основной код находится в магистрали, это также может работать как маркер для того, что находится в сборке (посмотрите между фиксациями версии).
+1 за использование сообщения о фиксации.
Для проекта я создал пользователя SVN под названием build.Машина сборки использовала этот логин для SVN.Всякий раз, когда машина / процесс сборки выполнял сборку, он также обновлял файл, и сообщение о фиксации SVN было идентификатором версии / другого идентификатора для сборки.
Затем мы также создали тег для этой сборки.Таким образом, в магистрали мы могли видеть сборки, когда / где они чередуются с другими изменениями.
Итак, мое предложение (самый простой способ сделать это) - создать другой файл с именем build (или что-нибудь еще, что вы хотите) и добавить к нему или просто изменить его в вашем скрипте / процессе сборки, а затем проверить его обратно в / зафиксировать с именем версии выпуска в качестве сообщения о фиксации.Просто.Затем он будет отображаться в ваших запросах истории.
Кроме того, если вы знаете, какие ревизии вы сравниваете, вы можете выполнить SVN diff, и вы увидите, какие файлы изменились и как между двумя ревизиями.
Не уверен насчет вашей общей настройки, но кто-то упомянул TortoiseSVN.Это определенно хорошее начало.Я лично использую Eclipse с подключаемым модулем subclipse, и это позволяет мне выполнять различия в графической среде между версиями.Пока у вас есть ваш проект, вы можете сравнивать любую ревизию с любой другой ревизией, и поэтому вам не нужно иметь всевозможное дублирование файлов.
Кроме того, мы обычно настраиваем три каталога в каждом репозитории.Ветви, Ствол и Метки.Как кто-то отметил, теги используются специально для идентификации выпуска.
Я сталкиваюсь с той же проблемой, и способ, которым я попытался исправить это для своей компании, заключается в том, чтобы иметь папку "release" в trunk, эта папка содержит только фактический исполняемый файл или то, что должно быть частью развертывания.
Я создаю новую папку для каждого выпуска, начинающуюся с '1.0.0.0' в папке 'release', а также помечаю код тем же именем папки выпуска, т.е. 1.0.0.0 в случае.
Я не уверен, что это правильный способ сделать это, но это решает мою проблему - найти исполняемый файл, который я развернул.
Если вы следуете обычному соглашению svn о "тегах / ветвях / магистрали" в корне вашего репозитория, разработчики, как правило, не захотят проверять весь репозиторий, только от магистрали вниз.
Я хотел бы предложить другой подход, который должен помочь решить заявленную вами проблему:создание примечаний к выпуску и просмотр различий в коде между выпусками.
Мы используем утилиту под названием SubWCRev, которая поставляется вместе с Tortoise SVN.У нас есть событие после сборки, которое захватывает номер версии SVN и помещает его в файл - в случае веб-сайтов мы помещаем это в файл с именем version.html.Затем в любой момент времени вы можете привязать свой релиз (будь то релиз, находящийся в настоящее время в QA, Prod или любой другой среде) к точному номеру редакции в SVN.Больше никаких пометок, больше никаких вопросов о том, что включено в релиз, больше никаких прослушивающих устройств для разработчиков, требующих обновить файл версии.
Чтобы определить, что было включено в выпуск, вы можете затем просто просмотреть журналы SVN из редакции X в редакцию Y и скопировать комментарии в документ и отредактировать, чтобы получился симпатичный документ с примечаниями к выпуску.То же самое верно для проверки кода или различий в выпусках;просто используйте номера версий, привязанные к вашему version.html, properties.cs, readme.txt и т.д.
Я бы также предложил создать какое-нибудь хранилище артефактов для хранения ваших сборок.Если вы переключитесь на использование номера редакции SVN в качестве номера вашей версии, вы всегда можете вернуться к этой точной редакции в SVN, что означает, что вам не нужны теги или копии вашего исходного кода для каждого выпуска, которые лежат в SVN.
К ТВОЕМУ СВЕДЕНИЮ,
SVN copy не является печатной копией, это просто связывание, поэтому не займет никакого места, кроме измененных файлов.И эти версии в любом случае займут место.Таким образом, создание копии для каждого выпуска не займет много места.
