Есть способ сделать это без ветвления, но это не очень красиво.
sign = -(int)((unsigned int)((int)v) >> (sizeof(int) * CHAR_BIT - 1));
http://graphics.stanford.edu/~seander/bithacks.html
Множество других интересных, слишком умных вещей на этой странице, тоже .. .
Для брелоков, опубликованных в официальном магазине брелоков ( https://jujucharms.com/ ), номер редакции выбирается брелком в магазине, когда брелок публикуется (впервые или когда новая версия выпущена). Хранилище брелоков всегда выбирает уникальную ревизию для каждого брелка, и содержимое файла «ревизия» не имеет значения. При развертывании подвесок из локального репозитория (локальных подвесок) файл редакции учитывается Juju, если это возможно. В любой среде Juju может быть только один брелок с указанным именем и номером ревизии (т. Е. В базе данных состояний Монго). При развертывании локального брелка, Juju пытается соблюдать ревизию внутри брелка, но если это невозможно (т. Е. Когда в БД состояния уже есть брелок с тем же именем и ревизией), последняя известная ревизия увеличивается и хранится. Пользователь уведомляется о фактической ревизии, с которой был развернут брелок:
juju deploy
из CLI появляется сообщение, говорящее Added charm "local:<series>/<name>-<revision> to the environment
(например, «локально: точный / wordpress-123» ); Итак, возвращаясь к вопросу: ожидается, что автор очарования будет хранить свои источники очарования в системе контроля версий где-нибудь, например, на панели запуска, в bitbucket, github и т. Д. Это правильный способ хранения информации о версии. и хранить всю историю. Файл ревизии в источнике чарма не гарантирует уникальности и не дает надежного способа ссылаться на конкретную версию чарма (в одной среде или в нескольких средах, использующих один и тот же шарм).