[GRASS-dev] Re: [GRASS GIS] #587: svn versions should better
reflect svn rev
GRASS GIS
trac at osgeo.org
Sun May 10 11:19:43 EDT 2009
#587: svn versions should better reflect svn rev
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: martinl
Type: enhancement | Status: reopened
Priority: major | Milestone: 6.4.0
Component: default | Version: 6.4.0 RCs
Resolution: | Keywords: g.version
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Comment (by hamish):
Hi,
after some more thought and investigation, gis.h's version while useful
isn't as good as it could be (could be unchanged for months, especially in
the stable branch)
- I propose to add a new -r flag to g.version to display raw
GIS_H_VERSION and GIS_H_DATE strings (no need to shell script style them
AFAICT). This will help people debug situations when the program detects a
libgis/module version mismatch. updated patch attached to this ticket.
either-
- add an hook script in the svn server to automatically write the present
rev and date to a file in the checkin branch. is that possible without
doubling the rev count? (or setting off an endless loop..). "svnlook
youngest .`" and "`svnlook date .`" might help. see http://svnbook.red-
bean.com/en/1.5/svn.reposadmin.create.html#svn.reposadmin.create.hooks
- or, modify the main Makefile and add "`svnversion -n .`" somewhere. see
http://subversion.tigris.org/faq.html#version-value-in-source But that
gives the rev of the overall repo, not just the branch we are using.
- so perhaps:
{{{
svn log --limit 1 --quiet --xml | grep 'revision=' | cut -f2 -d'"'
37100
svn log --limit 1 --quiet --xml | grep '<date>' | \
sed -e 's/T.*//' -e 's/.*>//'
2009-05-10
svn log --limit 1 --quiet | grep '(' | \
sed -e 's/.*(//' -e 's/)$//' | cut -f3,4 -d' '
May 2009
}}}
... the goal being that g.version could report like
{{{
GRASS GIS 7.0svn37123 (May 2009)
}}}
where the rev number/date was the current branch's latest modification.
This would end up in grass.py as grass.script.revision() or something so
the Help->About window in the GUI could report something accurate.
for formal releases I would guess to skip all the svn stuff and just
hardcode "6.4.0" and "1 May 2009".
?,
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/587#comment:14>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list