У меня есть SVNrepository, где файлы проверяются в этом формате.Номер версии SVN
<filename>.<ext>-rev<revision number>
Существует еще один файл, в который введен номер ревизии. Когда сборка выполнена, этот файл анализируется и файл с соответствующим номером ревизии берется и переименовывается в стандартное имя файла < filename>. < ext> и окончательная сборка выполнена.
Как я могу получить список изменений SVN перед отправкой?
Вы можете попробовать сделать svn up и получить последнюю версию и использовать этот rev plus один. Но, как сказал Марк Дикинсон, если кто-то еще обновит, будут проблемы.
Я бы попробовал другой подход.
Перед выполнением фиксации безопасный способ получить номер версии. Это потребует от клиентов возможности блокировки хранилища.
Зачем нужен новый файл для каждой новой версии? Я уверен, что есть лучшее решение проблемы, которую вы пытаетесь решить.
Я думаю, что у меня есть вся картина сейчас.
Сценарий таков:
Некоторый код извлечен из другой ветви репозитория. Исправлены ошибки, и полученные изменения были отправлены в этот репозиторий (номер проверки получен при регистрации).
С этими изменениями создается двоичная (библиотека). Эта библиотека является частью более крупного модуля, и этот двоичный файл проверяется в этом модуле как < двоичный> - < revno>. Файл make будет изменен для получения этого двоичного-revno и переименует его как < binary>. Он использует это при создании большего модуля.
Я думаю, что вы неправильно используете систему контроля версий (VCS). Вам не нужно указывать номера версий или даты в именах файлов при использовании VCS. VCS автоматически сохранит эту информацию в качестве метаданных.
Вместо проверки в новом файле каждый раз с новой версией/датой следует заменить старый файл. Старые файлы всегда будут доступны в истории VCS, если вам они понадобятся по какой-то причине. В дополнение к уменьшению помех это имеет то преимущество, что всегда сохраняет одно и то же имя файла, что упрощает автоматизацию.
Также, как правило, вы не хотите передавать скомпилированные двоичные файлы в исходное дерево. Вы должны только фиксировать файлы, необходимые для создания двоичных файлов (а именно, источника и файла makefile).
Если вы действительно хотите продолжить свой текущий план, у вас будет трудность. Невозможно узнать, какой номер версии вы получите до тех пор, пока фиксация не завершится успешно - это базовая проектная гарантия концепции атомной фиксации. Лучшее, что вы можете сделать, это добавить крюк после фиксации, который проверяет копию всего, что было только что зафиксировано, и переименовывает файл как номер ревизии.
Это означает, что изменение имени файла будет отображать более раннюю версию, чем та, в которой происходит изменение имени, но это позволит вам иметь номер версии имени файла, такой же, как и сделанные вами изменения, которые Я думаю, это то, что вы хотите.Этот метод также приведет к двум коммитам для каждого изменения. Я не рекомендую.
Посмотрите на «SvnRev», который в настоящее время доступен здесь:
http://www.compuphase.com/svnrev.htm
Похоже, вы пытаетесь осуществить какой-то CHANGELOG или системы мечения релиз, где пользователи могут выбирать различные выпущенные версии. Поэтому, полагая, что это то, что вы искали, это то, что я сделал в подобной ситуации. Я понимаю, что ваш вопрос - год, но, возможно, кто-то еще найдет это.
Я сохранил отдельный файл для хранения истории изменений, представляющих особый интерес. У меня есть проекты, где я делаю «официальный» установщик для всего нашего приложения. Обычно я не буду хранить сгенерированный код в системе управления версиями, но эти двоичные файлы мы рассматриваем как специальные. Нам нравится сохранять точный двоичный файл, который мы доставляем пользователю. Мы не хотим их перестраивать позже, а их хранение в SVN - это удобное злоупотребление контролем версий ...
Итак, я создаю двоичный файл установщика; передать двоичный файл установщика SVN; получить ревизию SVN установщика, которую я только что совершил; добавить версию/дату/примечания в файл CHANGELOG; и, наконец, я передаю файл CHANGELOG. Номер версии CHANGELOG будет один или более, чем установщик, но мне все равно, только номер ревизии установщика.
Для дополнительного удобства установщик копируется на веб-сервер и помещается под каталогом с номером ревизии установщика. Но мы всегда можем посмотреть заметки CHANGELOG, чтобы найти исправление установщика, которое мы хотим, и проверить его на эту ревизию.
Мы также можем использовать этот номер версии, чтобы проверить источник, используемый для сборки установщика (вы должны быть уверены, что никто не допустил изменений между исходным кодом checkout/build и фиксацией установщика). Если вы действительно не против тратить дисковое пространство, вы можете сделать тег; строить; и верните установщик обратно в тег. Конечно, у SVN нет тегов, поэтому вы бы сделали «svn copy»; но тогда реальная система тегов не позволит вам вносить изменения в нее.