Отслеживание версий, сборок, ревизий с помощью TortiseSVN

Question

Я единственный разработчик в проекте и уже давно пользуюсь tortoiseSVN. Теперь я хотел бы начать корректно работать с информацией о версии в проекте I.E. показать основную версию, второстепенную версию, обновление, сборку / ревизию в файлах журнала и в справке> О программе и т. д. *

Кажется, я не могу найти наилучшую форму. Ключевые слова svn Редакция кажется хорошей идеей, но информация, которую она вставляет в файлы, не является дружественным форматом для обновления ресурсов.

$rev$ is expanded to $Revision: 72 $ 

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

subwcrev c:\myproject c:\myproject\version.in c:\myproject\version.h  

он будет правильно писать текущую ревизию (72), но если я потом сделаю коммит (теперь ревизия 73) и проверим, что ревизия на более поздней стадии, реальная ревизия в проекте будет 72.

Я неправильно к этому отношусь? Стоит ли использовать другой подход и просто использовать автоматически увеличивающийся номер сборки в Visual Studio?

Что вы делаете в своей организации?

Answer 1

Прежде всего, вы используете теги в SVN для отслеживания ваших основных, второстепенных версий и т. Д.? Если бы не я, я бы начал там. Я создаю тег для каждого выпуска проекта и просто называю его 1.0, 1.1, 2.0 и т. Д.

Во-вторых, вы можете захотеть взглянуть на сервер непрерывной интеграции / сборки, такой как Cruise Control.

Answer 2

WordAligned имеет очень хорошую сводную статью, которую вы можете прочитать:

Проблема с номерами версий

Answer 3

Чтобы однозначно узнать, откуда кусок кода выходит из хранилища Subversion, вам нужны две информации:

1. номер редакции
2. ветвь (или тэг), откуда был извлечен код из

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

Для этого у меня есть пользовательская задача Ant , которая извлекает информацию и делает ее доступной как свойство Ant. Теперь вы можете включить их в файл свойств или класс Java.

Информация в моем случае отображается как "RELEASE_1.0 / 3454" или "TRUNK / 4565".

Нетехническое имя выпуска определяется как project.version в [build.properties][2]. Преимущества (...) в том, что вы можете переопределить это значение с помощью опции -D и повторно использовать тот же номер версии.

Answer 4

Хорошо, добавим часть ответа.

С точки зрения номера версии (не говоря уже о механике) номер ревизии Subversion довольно полезен - вы, вероятно, захотите контролировать Major и Minor, но тогда использовать номер ревизии оттуда (3-й или 4-й элемент) - это хорошо. Что еще более важно, даже если вы не отметили хранилище специально при выпуске, у вас все еще есть средства, чтобы добраться до кода в правильном состоянии.

Что приводит нас к механике - это будет несколько зависеть от языка. В сборке C # вы хотите изменить AssemblyInfo.cs, чтобы получить желаемые значения, на других языках я не уверен, что у меня в голове (буду редактировать в ответ на полезные комментарии!). Если вы сможете сделать это правильно, вы сможете идентифицировать код для всех ваших сборок в развернутом проекте.

Итак ... как вы получаете ваш AssemblyInfo.cs или его эквивалент прямо в сборке релиза? Наличие скрипта сборки (MSBuild или чего-либо другого) сделает это за вас - возможно, правильная сборка файла является болезненной (я уже делал это раньше), особенно когда вы начинаете добавлять сложности, такие как получение номеров ревизий , но есть и другие инструменты, которые могут помочь, что подводит меня к желательности сервера сборки.

Одна из вещей, которые я недавно обнаружил о TeamCity , заключается в том, что у вас есть системные переменные, которые вы можете вставить в свой скрипт сборки - поэтому у меня есть номер сборки TeamCity (включающий в себя SVN Revision и TeamCity счетчик build) как мой идентификатор - наши пакеты выпуска являются артефактами сборки, созданными TeamCity, поэтому моя способность идентифицировать конкретную сборку довольно хорошая. Я уверен, что другие серверы имеют аналогичные возможности. Я еще этого не сделал, но моим следующим шагом будет создание "релизных" сборок в Team City, которые я могу запустить вручную - я намерен автоматизировать этап создания тега в Subversion, а также некоторые другие этапы. (например, настройка web.config).

Больше указателей на ответы, чем реальный ответ, но инструменты уже есть (MSBuild с задачами сообщества, TeamCity, другие ...), просто вопрос их объединения.

Answer 5

Чтобы ответить на ваши вопросы:

Я неправильно к этому отношусь?

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

Должен ли я использовать другой подход и просто использовать автоматически увеличивающийся номер сборки в Visual Studio?

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

Что вы делаете в своей организации?

Мы используем теги . Когда файлы в нашем проекте находятся в точке, где мы можем развернуть их в рабочей среде, мы помечаем эту группу файлов (обычно назначая дату в формате% Y% m% d). Маркировка имеет много преимуществ.

Из этого тега мы будем строить и развертывать. У нас пока нет правильного сервера сборки или сервера непрерывной интеграции. Мы все еще такие же маленькие, как ты, но мы добираемся туда: -)

РЕДАКТИРОВАТЬ: я должен был отметить, что тегирование полезно, потому что оно скажет вам, в каком состоянии был весь ваш проект (это снимок всех файлов в вашем проекте независимо от номера ревизии). Это также удобно, если вам нужно вернуться к предыдущей ревизии. Это, конечно, после того, как вы пометили некоторое время.

Answer 6

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

Используйте инструмент Visual Studio для отслеживания номеров сборки и используйте Subversion для пометки релизов.