svn versions should better reflect svn rev

[hamish]

(moved here from osgeo4w bug # 37 ​http://trac.osgeo.org/osgeo4w/ticket/37 because it is seen both in the OSGeo4W and stand-alone installers)

• wx-vdigit: toolbar comes up but always "No vector map selected for editing.". In layer list I can choose "Start editing" and a "please wait while map is opened for editing" message comes up on the bottom status bar, but the "Stop editing" menu item never ungreys.

tested with both 6.4.0svn binary installers (latest). both r36287?

[martinl]

It should have been fixed in r36987 (?)

[hamish]

oh, ok. the installer's help "About GRASS" popup says it is based on r36287 so just a working off an older build.

sorry for the noise.

H

[hamish]

ps- what'll it take to get the digitizer working for the wingrass builds?

[martinl]

Replying to hamish:

oh, ok. the installer's help "About GRASS" popup says it is based on r36287 so just a working off an older build.

well, it's revision of wxgui.py not the latest revision of the build. Which is confusing.

M.

[martinl]

Replying to hamish:

ps- what'll it take to get the digitizer working for the wingrass builds?

to fix swig issues;-) Building vdigit/nviz extension is possible. Anyway they fail because of the swig error.

[hamish]

Replying to martinl:

Replying to hamish:

oh, ok. the installer's help "About GRASS" popup says it is based on r36287 so just a working off an older build.

well, it's revision of wxgui.py not the latest revision of the build. Which is confusing.

oh, that is rather misleading then. maybe another reason to expedite this g.version wish: ​http://thread.gmane.org/gmane.comp.gis.grass.devel/33031

and/or wrap up ($cleaned$) GIS_H_VERSION into a new grass.py function.

ps- what'll it take to get the digitizer working for the wingrass builds?

to fix swig issues;-) Building vdigit/nviz extension is possible. Anyway they fail because of the swig error.

this? ​http://thread.gmane.org/gmane.comp.gis.grass.devel/32222/focus=28609

Hamish

[hamish]

Replying to hamish:

and/or wrap up ($cleaned$) GIS_H_VERSION into a new grass.py function.

with some sort of two element output? (GRASS_VERSION_NUMBER, maybe GRASS_VERSION_DATE as well)

any ideas how to set GRASS_VERSION_DATE to match time of GIS_H_VERSION revision? "2009" covers a lot of development ground.

Hamish

[glynn]

Replying to hamish:

any ideas how to set GRASS_VERSION_DATE to match time of GIS_H_VERSION revision? "2009" covers a lot of development ground.

#define GIS_H_DATE "$Date$"

Converting it into the desired format will require some processing commands in configure.in or the Makefiles.

[hamish]

Replying to glynn:

 #define GIS_H_DATE "$Date$"

Converting it into the desired format will require some processing commands in configure.in or the Makefiles.

.... such as | cut -f2 -d'$' ? or do you mean date string format?

[glynn]

Replying to hamish:

Converting it into the desired format will require some processing commands in configure.in or the Makefiles.

.... such as | cut -f2 -d'$' ? or do you mean date string format?

I mean for any format other than the one SVN uses for $Date$.

[martinl]

Replying to hamish:

Replying to glynn:

 #define GIS_H_DATE "$Date$"

done in r37043. The patch for g.version attached (comments?)

M.

[martinl]

patch for g.version - svn_revision/date

[hamish]

Replying to martinl:

 #define GIS_H_DATE "$Date$"

done in r37043.

any objections to backporting this?

The patch for g.version attached (comments?)

• keep it easily parsable (on one line), and as backwards compatible as possible for existing script parsing.

• (for grass 7 only) s/GRASS/GRASS GIS/

• flags for diff't info? (only if needed)

• modify doc/howto_release.txt to say that GRASS_VERSION_DATE should be manually set to the release day for official releases, and for SVN builds take it from GIS_H_DATE?

• append the numeric value portion of GIS_H_VERSION (ie rev #) to GRASS_VERSION_NUMBER in the g.version output if 'svn' is found in GRASS_VERSION_NUMBER. so it automatically looks like "6.4.0svn32001"

This way it could be backwards compatible for g6 script parsing.

• is GRASS_VERSION_UPDATE_PKG relevant anymore for grass >= 5?

Hamish

[hamish]

hijacked ticket, but the orig was a dud anyway

[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

[hamish]

patch to display libgis rev

[martinl]

Replying to hamish:

> 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

why don't use

svn info

?

Martin

[jef]

Replying to martinl:

why don't use

svn info

?

or svnversion

[hamish]

thanks for mentioning svn info, I hadn't seen that.

However, AFAICT "svn info" and "svnversion" both give the rev number of the entire repo, not the latest change to that branch.

using the "svn log" method would keep the version unchanged for e.g. GRASS 5.4.2 since the last time that branch was actually modified. otherwise all branches+trunk versions change each time any modification is made globally (e.g. to grass-web or trunk), when in fact they haven't changed at all.

the downside of svn log is that it is rather slow and requires internet access.

Hamish

[hamish]

Replying to hamish:

the downside of svn log is that it is rather slow and requires internet access.

... which probably disqualifies it, not to mention the extra load on the server.

Hamish

[glynn]

Replying to hamish:

• 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.

You need to handle the case of compiling from a snapshot tarball on a system which doesn't have "svn".

[hamish]

I have now applied the new g.version -r flag in trunk (r37158) and devbr6 (r37233).

Ideas of where to go from here:

• in the wxGUI Help->About instead of just a misleading $Rev$, change the version number to be:

   wxPython GUI: $Rev$
   libgrass: $Rev$   (pull from `g.version -r`)
  

• some autoincrement a number in a file without triggering a rev script as a checkin-hook could maintain a global branch rev number & date for versioning use, but it would need to be done on the server and might be a PITA.

• we can use the 'svn info' command line tool to grab global-project rev (if svn is installed on the local system), as well as the branch's global rev (if svn is installed).

• proposal: grep the top .svn/ dir manually so it doesn't matter if svn is installed or not:

   REV=""
   if [ -d .svn ] ; then
      REV=`head -n 11 .svn/entries | tail -n 1`
      REV_DATE=`head -n 10 .svn/entries | tail -n 1`
   fi
  
   # would happen in build scripts, but e.g.
   FULL_VERSION="$GRASS_VERSION$REV"
  

line 11 of .svn/entries is the rev number of the last change in that branch. line 10 is the timestamp of that commit.

That would only happen if include/VERSION has "svn" in it.

Hamish

[hamish]

g.version -r backported to the 6.4 branch & now has $keyword$ lint removed.

[martinl]

Replying to hamish:

g.version -r backported to the 6.4 branch & now has $keyword$ lint removed.

I added 'svnversion' hack to configure in r39622. Seems to better then nothing. Please review it.

Martin

[neteler]

./configure ...
checking for source directory... /home/neteler/grass70
checking for build directory... /home/neteler/grass70
checking for svnversion... /usr/bin/svnversion   # <<= takes 30 seconds
checking for MacOSX App... no
checking for MacOSX architectures... no
...

It reports (I didn't make distclean but recompiled):

GRASS 7.0.svn (spearfish60):~ > g.version -c
GRASS 7.0.svn (2009) - r39627M

GRASS 7.0.svn (spearfish60):~ > g.version -r
GRASS 7.0.svn (2009) - r39627M
Revision: 39136
Date: 2009-09-12 08:17:35 +0200 (Sat, 12 Sep 2009)

(not sure where the M comes from and what 'Revision: 39136' might be)

"svn info" reports:

GRASS 7.0.svn (spearfish60):~/grass70 > svn info
Path: .
URL: https://svn.osgeo.org/grass/grass/trunk
Repository Root: https://svn.osgeo.org/grass
Repository UUID: 15284696-431f-4ddb-bdfa-cd5b030d7da7
Revision: 39627
Node Kind: directory
Schedule: normal
Last Changed Author: martinl
Last Changed Rev: 39626
Last Changed Date: 2009-10-26 23:10:31 +0100 (Mon, 26 Oct 2009)

Looks (almost) fine to me!

Markus

[martinl]

(not sure where the M comes from and what 'Revision: 39136' might be)

probably your working copy contains modified files. Martin

[martinl]

Replying to martinl:

Replying to hamish:

g.version -r backported to the 6.4 branch & now has $keyword$ lint removed.

I added 'svnversion' hack to configure in r39622. Seems to better then nothing. Please review it.

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

Martin

[hamish]

Replying to martinl:

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

please hold on that, I'd like to explore it more but won't be back in the office for a little time yet.

thanks, Hamish

[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

[glynn]

Replying to hamish:

'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.

You can use svnversion -c to get the last-changed revision, which is (presumably) what we want here.

[martinl]

Replying to glynn:

Replying to hamish:

'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.

You can use svnversion -c to get the last-changed revision, which is (presumably) what we want here.

Right, should be fixed in r40066.

[martinl]

Replying to hamish:

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);    

OK, done in r40090. g.version also reflects verbosity level.

g.version 
GRASS 7.0.svn (2009) 

g.version --q
GRASS 7.0.svn

g.version --v
GRASS 7.0.svn.40065 (2009)

[...]

Martin

[hamish]

I'd drop the --verbose option and just make the version number "solid". It's a neat trick, but the rev number is usually what you want to see and most folks won't discover the --v by chance.

The --quiet to turn off the date is an interesting idea though. I wonder if we can use something like the last line of svn info to better set the date. Manually setting it is not feasible and by-year is only so useful.

I understand that "GRASS 7.0.svn.40065" is easier to .split(), but still I would put my vote for "GRASS 7.0.svn40065". It matches historical and external conventions better. It's mostly cosmetic though. Any one else have an opinion?

any testing on how well it reverts to include/VERSION if the svnversion program (just downloaded weekly snapshot) or the .svn/ dir is not found (for final releases)?

thanks, Hamish

[martinl]

Replying to hamish:

I'd drop the --verbose option and just make the version number "solid". It's a neat trick, but the rev number is usually what you want to see and most folks won't discover the --v by chance.

The default version formatting would not probably contain info about revision number, e.g. as used for manual page header. We could add new flag or just modify existing -r to print both revision numbers(?)

Martin

[hamish]

Replying to hamish:

I'd drop the --verbose option and just make the version number "solid". It's a neat trick, but the rev number is usually what you want to see and most folks won't discover the --v by chance.

Replying to martinl:

The default version formatting would not probably contain info about revision number,

I disagree, when working with a SVN copy you always should know the exact rev number you are dealing with. 6.5svn or 7.0svn both cover code over years of development which represents completely different, well, everything. Without the rev number the version data is mostly useless.

e.g. as used for manual page header.

For things like help pages headers where you just want like "GRASS 6.4: Raster Modules" you can always parse the string (or probably easier to just hard code it..). For final releases all the extra noise is gone anyway and replaced with simply ".z", so it isn't a problem there.

2c, Hamish

[martinl]

Replying to hamish:

The default version formatting would not probably contain info about revision number,

I disagree, when working with a SVN copy you always should know the exact rev number you are dealing with. 6.5svn or 7.0svn both cover code over years of development which represents completely different, well, everything. Without the rev number the version data is mostly useless.

OK, probably you are right. Changed in r40111.

e.g. as used for manual page header.

For things like help pages headers where you just want like "GRASS 6.4: Raster Modules" you can always parse the string (or probably easier to just hard code it..). For final releases all the extra noise is gone anyway and replaced with simply ".z", so it isn't a problem there.

g.version --q currently prints only version number. Well, probably it's not a good idea, verbose levels are used for progress information which is not this case. What do you think?

[martinl]

Replying to martinl:

I disagree, when working with a SVN copy you always should know the exact rev number you are dealing with. 6.5svn or 7.0svn both cover code over years of development which represents completely different, well, everything. Without the rev number the version data is mostly useless.

OK, probably you are right. Changed in r40111.

BTW, what is preferable form of etc/VERSIONNUMBER? Current is

7.0.svn rxxxxx

[glynn]

Replying to hamish:

I'd drop the --verbose option and just make the version number "solid". It's a neat trick, but the rev number is usually what you want to see and most folks won't discover the --v by chance.

The --quiet to turn off the date is an interesting idea though.

I think that these are abusing the --v/--q options. If you want different formats, add specific options for them. That should probably include a -g option to output the individual components in var=val format for the benefit of scripts.

[hamish]

right, right. The GRASS_VERBOSE enviro variable should only have an effect on messages to stderr, not on what data gets written to stdout. if forgottenly set, it could cause many problems with parsing scripts.

I'm not sure if a -g flag is really needed, the string is easy enough to parse as it is, and almost all the parsing of it I've done in the past has to be to determine if I should send grass5 or grass6 commands.

Martin:

BTW, what is preferable form of etc/VERSIONNUMBER? Current is 7.0.svn rxxxxx

where's that used? as far as the startup welcome screen goes, I think "7.0.svn rxxxxx" is very good.

Hamish

[hamish]

Replying to hamish:

I'm not sure if a -g flag is really needed,

but if you want one, I have no real objection to it, other than it is completely redundant- there is already a $GRASS_VERBOSE enviro variable set.

Hamish

[hamish]

acckkkkk

s/GRASS_VERBOSE/GRASS_VERSION/

[neteler]

What is the state in GRASS 6.4? I tried right now and get:

GRASS 6.4.0svn (latlong_wgs84):~ > g.version -r
GRASS 6.4.0svn (2009)

because of

[neteler@north include]$ grep GIS_H_VERSION *
gis.h:#define GIS_H_VERSION "$Revision: 37101 $"
gis.h:#define G_gisinit(pgm) G__gisinit(GIS_H_VERSION, (pgm))
gis.h:#define G_no_gisinit() G__no_gisinit(GIS_H_VERSION)

but indeed we are at

[neteler@north include]$ svn up
At revision 40373.

The number comes from the check-in of the file itself:

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/include
Name   	 Size   	Rev  	 Age   	Last Change
...
gis.h   19.0 kB   37101   8 months    hamish:  backport GIS_H_DATE

The same applies to GRASS 7:

GRASS 7.0.svn (latlong_wgs84):~/grass64/include > g.version -r
GRASS 7.0.svn10129:40343M (2010)
Revision: 39888
Date: 2009-12-04 08:21:40 +0100 (Fri, 04 Dec 2009)

http://trac.osgeo.org/grass/browser/grass/trunk/include

Name   	 Size   	Rev  	 Age   	Last Change
...
gis.h   12.4 kB   39888   1 month    martinl:  synchronize vector modules (G_OPT_V_FIELD_ALL)

while

svn info | grep Revision
Revision: 40373

Perhaps we have to determine the rev version on compile time?

Markus

[hamish]

Markus wrote:

What is the state in GRASS 6.4? I tried right now and get:

This should be the revision of the latest commit to gis.h, which is why the -r flag says "GIS library revision number and time". This is what is important to qgis, core API, etc. The wx help->about window says "GIS Library Revision" which I'm sure will still confuse some folks in the absence of an over-all revision number, but none the less is fairly clear..

but indeed we are at [r40373]

note that is moslty just interesting for dev branch builds, for a tagged release the exact version of the codebase that the version number refers to is known.

Perhaps we have to determine the rev version on compile time?

which is what the svnversion -c added to ./configure in trunk is supposed to help with. I'm still waiting to gain confidence/test that this will be ok for folks without svn tools installed and/or a regular internet connection who have a copy of the snapshot to work with. Note the full release tarballs have the .svn/ stuff stripped away so in a full release svnversion -c or other tricks will not work.

bumping the target up to the devel branches.

Hamish

[hamish]

Replying to neteler:

The same applies to GRASS 7:

GRASS 7.0.svn (latlong_wgs84):~/grass64/include > g.version -r
GRASS 7.0.svn10129:40343M (2010)
Revision: 39888
Date: 2009-12-04 08:21:40 +0100 (Fri, 04 Dec 2009)

note that here Martin has built the current 'svnversion -c' rev number into the main version number (g.version with no flags).

the "a:bM" syntax indicates that your tree has local modifications.

Hamish

[glynn]

Replying to hamish:

the "a:bM" syntax indicates that your tree has local modifications.

The trailing "M" indicates modification; an unmodified tree would have "a:b". IMHO, the "a:" should be stripped; we're only interested in the last revision, not the first.

[hamish]

Replying to glynn:

Replying to hamish:

the "a:bM" syntax indicates that your tree has local modifications.

The trailing "M" indicates modification; an unmodified tree would have "a:b". IMHO, the "a:" should be stripped; we're only interested in the last revision, not the first.

so,

 GRASS_VERSION_SVN=
 AC_PATH_PROG(SVN_VERSION, svnversion, no)
 if test "$SVN_VERSION" != "no" ; then
-   GRASS_VERSION_SVN=`$SVN_VERSION -c`
+   GRASS_VERSION_SVN=`$SVN_VERSION -c | cut -f2 -d:`
 fi

Hamish

[hamish]

Glynn:

IMHO, the "a:" should be stripped; we're only interested in the last revision, not the first.

done in trunk, r40862.

Hamish

[hamish]

I just tested making trunk with svnversion missing, everything seems to behave well. I suggest to backport the svnversion thing to 6.5svn (but not 6.4).

Not for 6.4 because we still don't know what happens when svnversion is present but the code has had all .svn/ removed for release tarball.

Hamish

[hamish]

don't know what happens when svnversion is present but the code has had all .svn/ removed for release tarball.

it says "exported".

$ cd /tmp/
$ svnversion
exported

[neteler]

I revisited this today:

#### after svn up ; make distclean etc:
GRASS 6.4.0svn (spearfish60):~ > g.version -r
GRASS 6.4.0svn (2010)
Revision: 37101
Date: 2009-05-10 13:35:38 +0200 (Sun, 10 May 2009)

GRASS 6.4.0svn (spearfish60):~ > svn info grass64 | grep Rev
Revision: 42707
Last Changed Rev: 42681


#### after svn up ; make distclean etc:

GRASS 7.0.svn (spearfish60):~ > g.version -r
GRASS 7.0.svn42704 (2010)
Revision: 41297
Date: 2010-03-05 19:25:25 +0100 (Fri, 05 Mar 2010)

GRASS 7.0.svn (spearfish60):~ > svn info grass70 | grep Rev
Revision: 42707
Last Changed Rev: 42704

I would rather remove the -r flag than displaying outdated info. Of course a real solution would be preferred.

Markus

[hamish]

the next step is to backport ./configure -> Platform.make's svnversion -> GRASS_VERSION_SVN= magic to gr6.5.

I would rather remove the -r flag than displaying outdated info.

this is just the latest libgis api version, it's a bug if that is displayed everywhere AS the grass version, but it's not a bug in g.version and not actually outdated. It can be important to know the gis.h version once you start to build addons, so I'd argue to save the flag. just don't show that rev in large text on the start up screen as something important.

• note that folks building 6.4.0 from the tarball will likely not have Subversion installed and .svn/ dirs are stripped, so svnversion tricks will not work for final releases.

but that's not a problem because knowing the exact svn revision is only pertinent for svn checkouts, i.e. the exact svn version is already known for tagged releases so not very relevant. It is very useful for builds of long-lived development branches however (6.5, 7).

anyway, if it is eventually backported to 6.4, we need to ensure it doesn't get included in the final release, and we need to test the ./configure in the final tarball works correctly after .svn/ has been stripped, etc.

regards, Hamish

[hamish]

g.version svn checkout rev info backported to 6.5 in r45526, after some slight improvements in trunk (r45525). This is not a candidate for backporting to stable branches.

I wonder if version grafting should happen directly in Grass.make.in (g7: Platform.make.in) or as now in lib/init/Makefile?

Hamish

[martinl]

Replying to hamish:

g.version svn checkout rev info backported to 6.5 in r45526, after some slight improvements in trunk (r45525). This is not a candidate for backporting to stable branches.

I vote for backporting now, so before 6.4.1.RC7

[hamish]

Replying to hamish:

This is not a candidate for backporting to stable branches.

Replying to martinl:

I vote for backporting now, so before 6.4.1.RC7

This touches the core configure files, is not relevant in a tagged stable release, and is not tested well in 6.5svn. Possibly for the 6.4.2 stable cycle, even though it isn't a bugfix, but not as a last minute change in this one. No way.

regards, Hamish

ps- rc7?

[martinl]

Replying to hamish:

This touches the core configure files, is not relevant in a tagged stable release, and is not tested well in 6.5svn. Possibly for the 6.4.2 stable cycle, even though it isn't a bugfix, but not as a last minute change in this one. No way.

OK, so let me change at least milestone to 6.4.2 to keep record.

ps- rc7?

It's not common to publish final release after two months from the last RC (3 Jan). So I assume that there will RC7 before the final release.

[martinl]

Replying to martinl:

ps- rc7?

It's not common to publish final release after two months from the last RC (3 Jan). So I assume that there will RC7 before the final release.

Sorry, apparently I was so frustrated from never ending release circle of 6.4.0 that I can just think about RC6 or RC7;-) Of course I meant RC2.

[hamish]

Replying to martinl:

OK, so let me change at least milestone to 6.4.2 to keep record.

yes, I realized I picked the wrong box after I submitted it.

Still, it is only relevant for svn (nightly) builds, and is redundant for final releases. It's fundamentally a dev branch aid.

The release branch must be tested when .svn/ dirs and svn CLI tools are not present on the tarball/build machine. (in my quick tests last year I just su renamed those temporarily in /usr/bin/, see earlier comments in the ticket) It would not be nice to only discover a bug once the tarball was released and a non-dev tried it.

Hamish

[martinl]

Replying to hamish:

Still, it is only relevant for svn (nightly) builds, and is redundant for final releases. It's fundamentally a dev branch aid.

It's not right, it's not redundant for final release at all. Currently users have no information what is the revision of their build (g.version, wxGUI About window). It's common information which user could expect to know.

The release branch must be tested when .svn/ dirs and svn CLI tools are not present on the tarball/build machine. (in my quick tests last year I just su renamed those temporarily in /usr/bin/, see earlier comments in the ticket) It would not be nice to only discover a bug once the tarball was released and a non-dev tried it.

This feature has been introduced 17 months ago (r39622). Recently backported to devbr6 by you. What time is need to get finally this minor feature to release? ;-)

Hamish

[martinl]

Replying to hamish:

The release branch must be tested when .svn/ dirs and svn CLI tools are not present on the tarball/build machine. (in my quick tests last year I just su renamed those temporarily in /usr/bin/, see earlier comments in the ticket) It would not be nice to only discover a bug once the tarball was released and a non-dev tried it.

in this case GRASS_VERSION_SVN in include/Make/Grass remains empty and g.version -g reports

version=6.5.svn
revision=
date=2011

[martinl]

Replying to martinl:

The release branch must be tested when .svn/ dirs and svn CLI tools are not present on the tarball/build machine. (in my quick tests last year I just su renamed those temporarily in /usr/bin/, see earlier comments in the ticket) It would not be nice to only discover a bug once the tarball was released and a non-dev tried it.

in this case GRASS_VERSION_SVN in include/Make/Grass remains empty and g.version -g reports

> version=6.5.svn
> revision=
> date=2011

We are on the beginning of release circle for 6.4.2, I would vote for backporting this staff to releasebranch_6_4. It's a good time for that at this point.

[hamish]

Replying to hamish:

Still, it is only relevant for svn (nightly) builds, and is redundant for final releases. It's fundamentally a dev branch aid.

Replying to martinl:

It's not right, it's not redundant for final release at all. Currently users have no information what is the revision of their build (g.version, wxGUI About window). It's common information which user could expect to know.

It's completely redundant for a tagged release. In that case the version number of GRASS is all that is important and the svn version is simply an unused development artifact, 100% documented if they care to look it up (~10 sec in trac), but mostly irrelevant trivia to non-developers.

I suppose someone with a random nightly build of 6.4.svn would not know if they are before or after a point release, or someone just saw a "fixed in stable branch r12345" and wanted to quickly know if their GRASS was newer or older than that, but that's about it.

The release branch must be tested when .svn/ dirs and svn CLI tools are not present on the tarball/build machine. (in my quick tests last year I just su renamed those temporarily in /usr/bin/, see earlier comments in the ticket) It would not be nice to only discover a bug once the tarball was released and a non-dev tried it.

This feature has been introduced 17 months ago (r39622). Recently backported to devbr6 by you. What time is need to get finally this minor feature to release? ;-)

you miss my point. it has been tested in developers' svn builds, but never outside of svn builds, which is what a point release is (svn export). A beta1 or RC1 release is a suitable time to test that, so if you want to take responsibility it, by all means go for backport now.

And again, the primary value of this feature is in identifying custom svn builds, not final releases who's exact code-set is already known. (someone says there's a bug in 6.4.0rc2 you know exactly what assortment code they are talking about; if they say there's a bug in 6.5svn with no rev.. how old is that? what code is that? maybe we can learn the year. that's why this feature is important in dev branches)

anyway, nothing new to add, let's move on.

tx, Hamish

ps- I'd ask (everyone) that 6.4.1 tickets not be bulk reassigned to 6.4.2 in trac until we deal to these tickets specifically assigned to 6.4.2 already.

[martinl]

Replying to hamish:

It's not right, it's not redundant for final release at all. Currently users have no information what is the revision of their build (g.version, wxGUI About window). It's common information which user could expect to know.

It's completely redundant for a tagged release. In that case the version number of GRASS is all that is important and the svn version is simply an unused development artifact, 100% documented if they care to look it up (~10 sec in trac), but mostly irrelevant trivia to non-developers.

I suppose someone with a random nightly build of 6.4.svn would not know if they are before or after a point release, or someone just saw a "fixed in stable branch r12345" and wanted to quickly know if their GRASS was newer or older than that, but that's about it.

In one sentence: I can't see any point why user should not have access to this information (in the case he/she is interested about that).

The release branch must be tested when .svn/ dirs and svn CLI tools are not present on the tarball/build machine. (in my quick tests last year I just su renamed those temporarily in /usr/bin/, see earlier comments in the ticket) It would not be nice to only discover a bug once the tarball was released and a non-dev tried it.

This feature has been introduced 17 months ago (r39622). Recently backported to devbr6 by you. What time is need to get finally this minor feature to release? ;-)

you miss my point. it has been tested in developers' svn builds, but never outside of svn builds, which is what a point release is (svn export). A beta1 or RC1 release is a suitable time to test that, so if you want to take responsibility it, by all means go for backport now.

thanks, I can take this kind of responsibility, going to backport it.

[hamish]

Hi,

g.version in 6.4.2rc3 reports:

GRASS 6.4.2RC3exported (2012) 

because include/Make/Grass.make has:

GRASS_VERSION_SVN     = exported

(svnversion: "If invoked on a directory that is not a working copy, an

exported directory say, the program will output 'exported'.")

suggested patch:

Index: configure.in
===================================================================
--- configure.in	(revision 50554)
+++ configure.in	(working copy)
@@ -128,6 +128,9 @@
 AC_PATH_PROG(SVN_VERSION, svnversion, no)
 if test "$SVN_VERSION" != "no" ; then
    GRASS_VERSION_SVN=`$SVN_VERSION -c | cut -f2 -d:`
+   if test "$GRASS_VERSION_SVN" = "exported" ; then
+      GRASS_VERSION_SVN=
+   fi
 fi
 
 AC_SUBST(GRASS_VERSION_FILE)

todo: should g.version -g revision= report blank or just not be printed at all?

Hamish

[martinl]

Replying to hamish:

suggested patch:

+1 to apply the patch

todo: should g.version -g revision= report blank or just not be printed at all?

I would say "report black".

[martinl]

This issue should be solved before releasing 6.4.2. Increasing the priority.

[hamish]

patch applied in all branches with r50661,2,3

tested in 6.4.2rc3 by manually applying patch. seems ok from the command line and in the wxGUI.

Hamish

[hamish]

Hi,

I'm just looking at the 6.4.3 build on Debian/sid, and 'g.version -g' is not printing an empty "revision=" as expected, rather it is printing "revision=Unversioned directory". This is because of a change in 'svnversion' behavior between Subversion versions 1.6 and 1.7.

It's a problem because the space in the string breaks using "eval g.version -g".

suggested patch:

--- configure.in	(revision 57623)
+++ configure.in	(working copy)
@@ -130,7 +130,7 @@
 AC_PATH_PROG(SVN_VERSION, svnversion, no)
 if test "$SVN_VERSION" != "no" ; then
    GRASS_VERSION_SVN=`$SVN_VERSION -c | cut -f2 -d:`
-   if test "$GRASS_VERSION_SVN" = "exported" ; then
+   if test "$GRASS_VERSION_SVN" = "exported" -o "$GRASS_VERSION_SVN" = "Unversioned directory" ; then
       GRASS_VERSION_SVN=
    fi
 fi

any comments or objections before I commit?

Hamish

[hamish]

Replying to hamish:

'g.version -g' is not printing an empty "revision=" as expected, rather it is printing "revision=Unversioned directory". This is because of a change in 'svnversion' behavior between Subversion versions 1.6 and 1.7.

fixed in all branches, r57674-6.

Hamish