[GRASS-dev] Re: [GRASS GIS] #587: svn versions should better reflect svn rev

[GRASS GIS]

#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):

 > > If no objections I will backport it into devbr6 and then
 > > close the ticket.

 ok, I've had a chance to get back to this one, "-1" in its current form.


 instead of:
 {{{
     fprintf(stdout, "GRASS %s (%s) - r%s\n",
             GRASS_VERSION_NUMBER, GRASS_VERSION_DATE,
             GRASS_VERSION_SVN);
 }}}

 please consider:

 {{{
     fprintf(stdout, "GRASS %s.svn%s (%s)\n",
             GRASS_VERSION_NUMBER, GRASS_VERSION_SVN,
             GRASS_VERSION_DATE);
 }}}

 a number of things parse the g.version output in varying ways.
 as it is hard to predict what that will be and it would be a
 shame to break them, a x.y.svn12345 version string would be more
 robust.



 lib/init/Makefile adds the rev number to GRASS_VERSION_NUMBER,
 then g.version does it again.. ? what am I missing..




 'svnversion' gives the wrong answer. e.g. for 6.2svn the result should
 be 6.2.svn30152 but after 'cd releasebranch_6_2; svn up' svnversion
 reports r40065. ie the global repo rev number, not the latest change
 to the branch rev.; is the relevant one.

 see comment:17, proposal in comment:20, and
 http://trac.osgeo.org/grass/log/grass/branches/releasebranch_6_2

 the proposal in comment:20 also covers the case when a weekly source
 snapshot has been downloaded but subversion is not installed (which
 is the expected situation for non-devs).

 As Markus noted, svnversion scans the entire tree, which takes some time.
 On the plus side we'd know in bug reports if the code is as expected
 or if it has been altered. (that's what the "M" at the end of the rev
 means)

 'svn info' is no good due to the global rev number problem as described
 above.


 I'm not very good at reading autoconf magic, but it is written so
 that for formal releases with all .svn/ removed it plays nice, yes?



 consider adding final version number to the ./configure end-of-script
 feature summary.


 thanks,
 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/587#comment:27>
GRASS GIS <http://grass.osgeo.org>