Pull to refresh

Comments 13

Гораздно удобнее пользоваться svn:keywords в т.ч. $Revision:$ к примеру в strings.xml и выводить вы логе или прямо на активити.
Тогда вы возможно не подозреваете о проблеме, и вот почему…
Создаём два подопытных каталога, в каждых добавляем по файлу.
$ 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.
Я ant не использую, у меня git hooks для этой цели.
Имхо вместо versionName лучше использовать versionCode (он ближе по сути), плюс его не надо реплейсить регэкспом, достаточно просто определить нужную переменную.

А вообще это задача для билд-сервера всё-таки, например, в TeamCity можно сделать таким способом: blog.thevery.info/2011/06/updating-android-version-number-during.html
Я кстати немного не так делал. Я делал svn log с выводом в формате xml, а затем по xpath тупо хавал последний элемент. Таким образом получал и юзера, сделавшего последний коммит, и собственно ревизию. А саму версию получал слиянием ветки (она в репозе в виде папок вида 1.2.3) и собственно ревизии.

Кстати, использую эту технику не для Android, а для формирования версионного ресурса у c++ программ под винду.
Я вот так с git делаю: чтобы получить номер последнего изменения, запускаю 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.

Articles