Hi,
I think that g.version -r should output the content of -g since the output
of -r is confusingly lagging behind:
# as of today:
GRASS 7.0.svn (eu_laea):~ > g.version -r
GRASS 7.0.svn (2012)
libgis Revision: 51177
libgis Date: 2012-03-28 16:36:45 +0200 (Wed, 28 Mar 2012)
# but (white space taken out):
GRASS 7.0.svn (eu_laea):~ > head software/grass70/.svn/entries
10
dir
51601
https://svn.osgeo.org/grass/grass/trunk
https://svn.osgeo.org/grass
2012-05-08T11:33:40.784753Z
# this output looks ok:
GRASS 7.0.svn (eu_laea):~ > g.version -g
version=7.0.svn
revision=51601
date=2012
I would suggest that g.version -r be changed to output the values of -g.
Markus
Markus Neteler wrote:
I think that g.version -r should output the content of -g since the output
of -r is confusingly lagging behind:
Outputting additional information shouldn't be a problem, but the SVN
revision cannot replace the libgis revision.
The SVN revision shown by -g is only available if the svnversion
program is present on the build system and the source tree was
obtained from SVN (rather than e.g. a snapshot tarball). Otherwise,
the GRASS_VERSION_SVN make variable will be the empty string.
The libgis revision is what the "incompatible library version" check
uses.
Personally, I'm more concerned about the fact that -g doesn't include
the libgis revision than the fact that -r doesn't include the SVN
revision.
--
Glynn Clements <glynn@gclements.plus.com>