get_svn_revision() does not work in Subversion 1.7.x and later

Originally posted by [b]KeiKun[/b]
hmm
i tried
but mine still shows the rev #

im using Tortoise SVN x32 1.6.16

but still showing the revision..

Originally posted by [b]Brian[/b]
[quote name='KeiKun' timestamp='1324492582' post='5857']
im using Tortoise SVN x32 [b]1.6.16[/b]
[/quote]

It works for you because 1.[color=#0000ff][b]6[/b][/color].16 is BEFORE 1.[color=#ff0000][b]7[/b][/color]
As I stated in the first post, this bug only affects Subversion clients 1.7.x and later.

Originally posted by [b]Mercurial[/b]
My suggestion for this is to generate a version.txt file on pre compilation process

or

get the version online

Originally posted by [b]Brian[/b]
but how will the "pre-compilation process" get the SVN version though?
I guess 'svnversion' command.. but not all Windows users pick "install command line client".

[quote name='Mercurial' timestamp='1324520281' post='5862']
or get the version online
[/quote]
The point of 'get_svn_revision' (used in @version command) is to display the version of the [b]local[/b] copy.

Another solution is add SQLite support to read the Subversion medata db =p

Originally posted by [b]Ind[/b]
could you upload a version of that file to me? perhaps i could get the info from it without adding full sqlite support -- which would be used only for that.

Originally posted by [b]Brian[/b]
[attachment=369:Subversion_1.7_sqlite_db.zip]

Here are the SQL queries I was thinking of:
[sql]SELECT MAX(`revision`) FROM `NODES`;[/sql]
or
[sql]SELECT `revision` FROM `NODES` WHERE `repos_path`='trunk';[/sql]

Or were you thinking of reading the binary file directly and looking for "revision" in it?

Originally posted by [b]Ind[/b]
to the other lovely developers: I've fixed it for unix/gcc on [rev=15211]. I have absolutely no idea why it doesn't work on windows though |: make yourself comfortable to fix it if you have any clue

Originally posted by [b]Ind[/b]
Fixed in [rev=15212] by xazax

Originally posted by [b]Brian[/b]
actual revision was 15866, but detected as [color=#0000ff]15795[/color]12

[attachment=1474:r1579512.PNG]

Originally posted by [b]Ind[/b]
I wasn't able to reproduce o-o I wonder what could be different in your files for it not to be reading the value properly

Originally posted by [b]EvilPuncker[/b]
here is working fine still

Originally posted by [b]xazax[/b]
Yeah this is a tricky thing. We do not read the SQLite properly, just using a method that is more or less accurate. Even though it should not report higher revision at all. Is it possible the metadata got corrupted?

I did a small refinement on that code, please test, if it helps:
[codebox]
Index: core.c
===================================================================
--- core.c (revision 15868)
+++ core.c (working copy)
@@ -193,12 +193,14 @@
* subversion 1.7 introduces the use of a .db file to store it, and we go through it
* TODO: In some cases it may be not accurate
**/
- if(!(*rA_svn_version) && ((fp = fopen(".svn/wc.db", "rb")) != NULL || (fp = fopen("../.svn/wc.db", "rb")) != NULL)) {
+ if(!(*rA_svn_version) && ((fp = fopen("../.svn/wc.db", "rb")) != NULL || (fp = fopen(".svn/wc.db", "rb")) != NULL)) {
char lines[64];
+ char* pos;
int revision,last_known = 0;
while(fread(lines, sizeof(char), sizeof(lines), fp)) {
- if( strstr(lines,"!svn/ver/") ) {
- if (sscanf(strstr(lines,"!svn/ver/"),"!svn/ver/%d/%*s", &revision) == 1) {
+ pos = lines;
+ while( (pos = strstr(pos+1, "!svn/ver/")) ) {
+ if (sscanf(pos, "!svn/ver/%d/%*s", &revision) == 1) {
if( revision > last_known ) {
last_known = revision;
}

[/codebox]

Originally posted by [b]Brian[/b]
Thanks, I will test when I get home on the computer that was reporting r[color=#0000FF]15795[/color]12.

PS: (on another computer) I found when I did TortoiseSVN > Clean Up --> detected as 1586[color=#FF0000]4[/color]. But if I do SVN Update again, it is correctly detected as 15869.

Originally posted by [b]KeiKun[/b]
is this normal?
my svn is using 15869
then
i updated my svn to rev 15860
then i do recompile
but still
my emu shows up 15869

Originally posted by [b]Brian[/b]
I applied your patch, but it still detects the wrong version.
(I updated my working copy) now it's 15[b]872[/b] but detected as "15[b]251[/b][color=#ff0000]12[/color]".

Here's my wc.db for testing: [attachment=1505:wc.zip]
I opened it in a hex editor and searched for "1525112" -- there are NO occurrences
but there are 2 places with "15251" that doesn't follow the pattern [font=courier new,courier,monospace]/!svn/ver[b]/[/b]15251[b]/[/b][/font]

[attachment=1506:15251__.png]

Is the character after "15251" being detected as a number?

Originally posted by [b]Brian[/b]
[quote name='Ind' timestamp='1334558697' post='8390']
I wasn't able to reproduce o-o I wonder what could be different in your files for it not to be reading the value properly
[/quote]

I am using TortoiseSVN-1.7.9.23248-[b]x64[/b]
and can reproduce on Windows 7, Windows Server 2008 R2, and Windows 8 Release Preview.


Anyone with TortoiseSVN 1.7.9 [b][i]32-bit[/i][/b], do you have this issue?

Originally posted by [b]flaviojs[/b]
Linking to related bugreport: http://eathena.ws/forum/tracker/issue-5094-eathena-svn-version-unknown/

Originally posted by [b]Brian[/b]
Thanks flaviojs! Merged in [rev=16807].

Updating status to: [b]Fixed[/b]
(it's more Fixed than it was before, but not as accurate as the 'svnversion' command or querying the SQLite db).

Originally posted by [b]Brynner[/b]
thanks [url="http://rathena.org/board/user/5508-flaviojs/"]flaviojs[/url]

Originally posted by [b]Brian[/b]
Related: [bug=6798]

was fixed by flaviojs