Номер редакции SVN

Question

У меня есть SVNrepository, где файлы проверяются в этом формате.

<filename>.<ext>-rev<revision number>

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

Как мне получить номер списка изменений SVN перед отправкой?

Answer 1

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

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

Также, как правило, вы не хотите фиксировать скомпилированные двоичные файлы в исходное дерево. Вы должны фиксировать только файлы, необходимые для сборки двоичных файлов (а именно, исходный код и make-файл).

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

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

Answer 2

Не существует безопасного способа получения номера редакции перед выполнением фиксации. Это потребует от клиентов возможности блокировать хранилище.

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

Answer 3

Вы можете попробовать сделать svn up и получить последнюю ревизию и использовать эту версию плюс один. Но, как сказал Марк Дикинсон, если кто-то еще обновится, будут проблемы.

Я бы попробовал другой подход.

Answer 4

Посмотрите на "SvnRev", который в настоящее время доступен здесь:

http://www.compuphase.com/svnrev.htm

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

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

Итак, я создаю свой бинарный файл установщика; передайте двоичный файл установщика в SVN; получить SVN-версию установщика, которую я только что зафиксировал; добавить ревизию / дату / примечания в файл с именем CHANGELOG; и наконец я фиксирую файл CHANGELOG. Номер ревизии CHANGELOG будет один или больше, чем номер инсталлятора, но мне важны только номера ревизии установщика.

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

Мы также можем использовать этот номер редакции для проверки источника, использованного для сборки установщика (вы должны быть уверены, что никто не внес изменений между вашей проверкой / сборкой исходного кода и фиксацией установщика). Если вы действительно не против тратить место на диске, вы можете сделать тег; строить; и верните установщик обратно в тег. Конечно, у SVN нет тегов, поэтому вы должны сделать «svn copy»; но тогда реальная система тегов не позволит вам зафиксировать изменения обратно.

Answer 5

Я думаю, что теперь у меня есть вся картина.

Сценарий таков:

Некоторый код извлечен из другой ветки хранилища. Исправления внесены, и полученные изменения переданы в этот репозиторий (номер ревизии получен при регистрации).

Бинарный файл (библиотека) создается с этими изменениями. Эта библиотека является частью большего модуля, и этот двоичный файл отмечен в этом модуле как - . Файл make модифицируется, чтобы получить этот двоичный файл revno и переименовать его в . Он использует это при создании большего модуля.