Comments 13
Гораздно удобнее пользоваться svn:keywords в т.ч. $Revision:$ к примеру в strings.xml и выводить вы логе или прямо на активити.
Тогда вы возможно не подозреваете о проблеме, и вот почему…
Создаём два подопытных каталога, в каждых добавляем по файлу.
Добавляем svn:keywords Rev и LastChangedRevision во второй файл, коммитим.
Проверяем содержимое обоих файлов — видим, что второй теперь содержит номер ревизии.
Добавляем во второй файл строку, фиксируем, снова замечаем изменения.
Смотрим что нам выдают svn info и svnversion.
Теперь меняем первый файл, а второй не трогаем.
Смотрим что нам выдают svn info и svnversion.
А теперь убеждаемся в том, что второй файл остался нетронутым.
Это потому, что он не менялся. Он всё ещё хранит номер 2 ревизии, тогда как версия рабочей копии уже 3.
Создаём два подопытных каталога, в каждых добавляем по файлу.
$ md 1
$ md 2
$ echo "first file">1\1.txt
$ echo "$Rev$ and $LastChangedRevision$">2\2.txt
$ svn add 1
A 1
A 1\1.txt
$ svn add 2
A 2
A 2\2.txtДобавляем svn:keywords Rev и LastChangedRevision во второй файл, коммитим.
$ svn propset svn:keywords "Rev LastChangedRevision" 2\2.txt
property 'svn:keywords' set on '2\2.txt'
$ svn --message "first commit" commit
Adding 1
Adding 1\1.txt
Adding 2
Adding 2\2.txt
Transmitting file data ..
Committed revision 1.Проверяем содержимое обоих файлов — видим, что второй теперь содержит номер ревизии.
$ type 1\1.txt
"first file"
$ type 2\2.txt
"$Rev: 1 $ and $LastChangedRevision: 1 $"Добавляем во второй файл строку, фиксируем, снова замечаем изменения.
$ echo one more message>>2\2.txt
$ svn --message "second commit" commit
Sending 2\2.txt
Transmitting file data .
Committed revision 2.
$ type 2\2.txt
"$Rev: 2 $ and $LastChangedRevision: 2 $"
one more messageСмотрим что нам выдают svn info и svnversion.
$ svn info
Revision: 0
$ svnversion
0:2Теперь меняем первый файл, а второй не трогаем.
$ echo third invisible commit>>1\1.txt
$ svn --message "third commit" commit
Sending 1\1.txt
Transmitting file data .
Committed revision 3.Смотрим что нам выдают svn info и svnversion.
$ svn info
Revision: 0
$ svnversion
0:3А теперь убеждаемся в том, что второй файл остался нетронутым.
$ type 2\2.txt
"$Rev: 2 $ and $LastChangedRevision: 2 $"
one more messageЭто потому, что он не менялся. Он всё ещё хранит номер 2 ревизии, тогда как версия рабочей копии уже 3.
Даже учитывая такую особенность, номер ревизии стоит добавлять в strings.xml
Версию можно сохранить и в strings.xml, а не AndroidManifest.xml, для этого достаточно отредактировать svn-revision.build.xml. Только не надо пытаться сделать это с помощью svn:keywords.
Что касается использования bash-скриптов, то можно придумать ещё способы получения версий. Я например предпочитаю пользоваться subwcrev.
Буду очень признателен, если пришлёте Build Ant команды для git, чтобы я вставил их в статью. Сам этого сделать не могу — везде использую subversion.
Что касается использования bash-скриптов, то можно придумать ещё способы получения версий. Я например предпочитаю пользоваться subwcrev.
Буду очень признателен, если пришлёте Build Ant команды для git, чтобы я вставил их в статью. Сам этого сделать не могу — везде использую subversion.
А вот, кстати, мой скрипт для добавления ревизии в strings.xml для git.
github.com/beshkenadze/androidhooks
github.com/beshkenadze/androidhooks
А для mercurial можно что-нибудь придумать?
Имхо вместо versionName лучше использовать versionCode (он ближе по сути), плюс его не надо реплейсить регэкспом, достаточно просто определить нужную переменную.
А вообще это задача для билд-сервера всё-таки, например, в TeamCity можно сделать таким способом: blog.thevery.info/2011/06/updating-android-version-number-during.html
А вообще это задача для билд-сервера всё-таки, например, в TeamCity можно сделать таким способом: blog.thevery.info/2011/06/updating-android-version-number-during.html
Я кстати немного не так делал. Я делал svn log с выводом в формате xml, а затем по xpath тупо хавал последний элемент. Таким образом получал и юзера, сделавшего последний коммит, и собственно ревизию. А саму версию получал слиянием ветки (она в репозе в виде папок вида 1.2.3) и собственно ревизии.
Кстати, использую эту технику не для Android, а для формирования версионного ресурса у c++ программ под винду.
Кстати, использую эту технику не для Android, а для формирования версионного ресурса у c++ программ под винду.
Я вот так с git делаю: чтобы получить номер последнего изменения, запускаю
Всё это делает python-скрипт, который вызывается из Eclipse как externalToolBuilder.
git describe --always. А ещё запускаю git status --porcelain и смотрю, есть ли в выдаче строки, не начинающиеся с ??.Всё это делает python-скрипт, который вызывается из Eclipse как externalToolBuilder.
Я вот так с git делаю: чтобы получить номер последнего изменения, запускаю git describe --always.
Аналогично. Кроме того, у git describe есть ещё интересные ключики:
- --tags — добавлять название последнего тэга, если есть
- --dirty=+ — помечать грязную рабочую копию плюсиком
- --abbrev=5 — урезать хэш до 5 символов
Кстати, раз уж речь зашла об альтернативных VCS, в Mercurial для получения номера текущей ревизии годится команда
hg heads --template {rev}
Sign up to leave a comment.
Генерация версии android приложения из ревизии subversion и git