отображение версии (номера ревизии) в окошке About из системы контроля версий

SVN: http://www.startupcto.com/server-tech/subversion/setting-the-id-tag

А что в этом костыльного? Костыль - это $Id$, предложенный постом выше.

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

это покажет ревизию самого файла, когда он последний раз изменялся

бгг а засунуть этот rev в один заголовочный файл?

Бгг, а как называется парная к дислексии болезнь, приводящая к невозможности выражения своих мыслей?

очевидно, что это я тебе выразить не смогу.

Поделитесь историями успеха

Проект собирался с помощью SCons, в котором скрипты на питоне. Вот эти скрипты заодно вызывали git и генерировали хедер. SCons может обновлять цели не по времени модификации, а по md5, поэтому можно переписывать хедер каждую сборку.

sectoid@dagon:~/prj$ git log --pretty=%H -1 HEAD 
8b660795ea002804e06876dd5c7ee318f1816501

или

sectoid@dagon:~/prj$ git log --pretty=%h -1 HEAD 
8b66079

Как-то так. Дальше сам думаю дойдешь.

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

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

Хэш указывается в скобках, после версии. А у вас, уважаемый, версия растет на каждый коммит?

у вас, уважаемый, версия растет на каждый коммит?

В приличных системах (не git) так и происходит, но пойнт в том, что хэш ревизии (как и ее номер, впрочем) полезен как дополнение к человек-читабельной метке вроде 0.x.y.z.

Идея со скриптом нормальная, так будет правильно.

В приличных системах (не git) так и происходит,

я говорил о версии проекта, а не о «номере ревизии». В распределенной системе понятие плоского «номера ревизии» несколько неоднозначно, и подход git'а мне здесь как раз нравится.

но пойнт в том, что хэш ревизии (как и ее номер, впрочем) полезен как дополнение к человек-читабельной метке вроде 0.x.y.z.

Об этом я и хотел сказать в моем комментарии.

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

git log "--pretty=format:%h" -n 1

а дальше воткнуть результат при сборке туда куда тебе будет вдобнее.

Самый вменяемый вариант - скрипт, к которому приложил руку сам Эрик С. Реймонд - https://github.com/Autorevision/autorevision

На входе поддерживает git, svn, hg и bzr, на выходе - любые ЯП. Вроде на большинство граблей там уже наступили и вцелом это видится намного более надёжным решением чем ручной вызов vcs для получения ревизии.

А вообще, следует заметить что сама идея глубоко порочна. Для официальных релизов в исходниках должна быть прописана нормальная версия, а те кто собирается из VCS не будут смотреть ни в какие about ибо ревизию знают и так. При этом добавление средств для вытаскивания этой самой ревизии увеличивает хрупкость сборки - я лично натыкался на то что софт не собирался потому что скрипт получающий ревизию хотел bash'а которого у меня нет и никогда не будет. Пришлось выкорчёвывать этот скрипт к чёртовой матери.

Алсо, это в любом случае ненадёжно. Допустим, оно умеет вытащить ревизию из vcs чекаута. А если я сделал svn export / git archive или скачал тарболл? А если у меня в ~ есть свой .git для конфигов? С большой вероятностью любой скрипт тут либо упадёт, либо напишет не ту ревизию, либо напишет полную чушь. Так что рекоммендую от этой идеи вообще отказаться.

PS. CVS'овский $Id$ на самом деле - самый вменяемый вариант с точки зрения удобства его использования, потому что не требует лишних телодвижений, CVS гарантирует его присутствие и его можно встроить в любой исходник или файл системы сборки.

Но другое дело что его можно использовать _только_ в CVS - в svn он прикручивается сбоку и через одно место, а больше нигде, насколько я знаю, не прикручивается. И с точки VCS он как раз абсолютно невменяем, ибо модифицирует неизменяемые файлы, и создаёт кучу проблем, в частности при использовании внешнего diff.

Поделитесь историями успеха

А что у тебя используется для сборки проекта и генерации мэйкфайлов?

+1, поэтому у меня скрипт генерации метки ревизии берет либо версию из deb-пакета, либо вручную прописанную версию типа 0.x.y-dev

autoconf, automake

интересно, поизучаю

Для официальных релизов в исходниках должна быть прописана нормальная версия,

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

В configure.ac добавь проверку на каталог .git/.svn и запись версии во флаги компиляции.

В коде делай #ifdef REVISION

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

Эмм, и что ты делаешь в таком случае, делаешь tag slip и/или перепаковываешь тарболлы под той же версией? Тогда знай что мантейнеры пакетов в дистрибутивах, пользователи и зеркала тебя проклинают страшными словами, ибо у них перестают совпадать контрольные суммы и всё ломается. Для хотфиксов как раз и существует minor version.

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

И вместо увеличения версии ты хочешь добавить к ней хэш? Ахренеть вообще.

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

чтоб разрыва в нумерации между выпущеными релизами не было

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

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

Какого разрыва? Почитайте http://semver.org - в схеме версий X.Y.Z на каждый релиз с новой функциональностью вы увеличиваете Y, а на хотфикс - Z (я кстати, напутал - это называется patch version, а не minor).