[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