Issue Information
-
#005138
-
2 - Fair
-
Fixed
Issue Confirmations
-
Yes (0)No (0)
0
get_svn_revision() does not work in Subversion 1.7.x and later
Posted by Hercules Bot on 21 December 2011 - 04:50 PM
Originally posted by Brian
In Subversion 1.7, they changed the format and storage location of metadata:
http://subversion.ap.../1.7.html#wc-ng
http://tortoisesvn.n...leasenotes.html
In Subversion 1.7, they changed the format and storage location of metadata:
http://subversion.ap.../1.7.html#wc-ng
http://tortoisesvn.n...leasenotes.html
- working copies have just one .svn directory in the root of the working copy (instead of a .svn directory in every directory)
- the metadata is stored in an SQLite-backed database (instead of flat files)
Originally posted by KeiKun
hmm
i tried
but mine still shows the rev #
im using Tortoise SVN x32 1.6.16
but still showing the revision..
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 Brian
It works for you because 1.6.16 is BEFORE 1.7
As I stated in the first post, this bug only affects Subversion clients 1.7.x and later.
im using Tortoise SVN x32 1.6.16
It works for you because 1.6.16 is BEFORE 1.7
As I stated in the first post, this bug only affects Subversion clients 1.7.x and later.
Originally posted by Mercurial
My suggestion for this is to generate a version.txt file on pre compilation process
or
get the version online
My suggestion for this is to generate a version.txt file on pre compilation process
or
get the version online
Originally posted by Brian
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".
Another solution is add SQLite support to read the Subversion medata db =p
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".
The point of 'get_svn_revision' (used in @version command) is to display the version of the local copy.or get the version online
Another solution is add SQLite support to read the Subversion medata db =p
Originally posted by Ind
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.
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 Brian
Here are the SQL queries I was thinking of:
or
Or were you thinking of reading the binary file directly and looking for "revision" in it?
Here are the SQL queries I was thinking of:
SELECT MAX(`revision`) FROM `NODES`;
or
SELECT `revision` FROM `NODES` WHERE `repos_path`='trunk';
Or were you thinking of reading the binary file directly and looking for "revision" in it?
Originally posted by Ind
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
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 Ind
Fixed in [rev=15212] by xazax
Fixed in [rev=15212] by xazax
Originally posted by Brian
actual revision was 15866, but detected as 1579512
actual revision was 15866, but detected as 1579512
Originally posted by Ind
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
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 EvilPuncker
here is working fine still
here is working fine still
Originally posted by xazax
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:
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:
<br />Index: core.c<br />===================================================================<br />--- core.c (revision 15868)<br />+++ core.c (working copy)<br />@@ -193,12 +193,14 @@<br /> * subversion 1.7 introduces the use of a .db file to store it, and we go through it<br /> * TODO: In some cases it may be not accurate<br /> **/<br />- if(!(*rA_svn_version) && ((fp = fopen(".svn/wc.db", "rb")) != NULL || (fp = fopen("../.svn/wc.db", "rb")) != NULL)) {<br />+ if(!(*rA_svn_version) && ((fp = fopen("../.svn/wc.db", "rb")) != NULL || (fp = fopen(".svn/wc.db", "rb")) != NULL)) {<br /> char lines[64];<br />+ char* pos;<br /> int revision,last_known = 0;<br /> while(fread(lines, sizeof(char), sizeof(lines), fp)) {<br />- if( strstr(lines,"!svn/ver/") ) {<br />- if (sscanf(strstr(lines,"!svn/ver/"),"!svn/ver/%d/%*s", &revision) == 1) {<br />+ pos = lines;<br />+ while( (pos = strstr(pos+1, "!svn/ver/")) ) {<br />+ if (sscanf(pos, "!svn/ver/%d/%*s", &revision) == 1) {<br /> if( revision > last_known ) {<br /> last_known = revision;<br /> }<br /><br />
Originally posted by Brian
Thanks, I will test when I get home on the computer that was reporting r1579512.
PS: (on another computer) I found when I did TortoiseSVN > Clean Up --> detected as 15864. But if I do SVN Update again, it is correctly detected as 15869.
Thanks, I will test when I get home on the computer that was reporting r1579512.
PS: (on another computer) I found when I did TortoiseSVN > Clean Up --> detected as 15864. But if I do SVN Update again, it is correctly detected as 15869.
Originally posted by KeiKun
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
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 Brian
I applied your patch, but it still detects the wrong version.
(I updated my working copy) now it's 15872 but detected as "1525112".
Here's my wc.db for testing:
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 /!svn/ver/15251/
Is the character after "15251" being detected as a number?
I applied your patch, but it still detects the wrong version.
(I updated my working copy) now it's 15872 but detected as "1525112".
Here's my wc.db for testing:
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 /!svn/ver/15251/
Is the character after "15251" being detected as a number?
Originally posted by Brian
I am using TortoiseSVN-1.7.9.23248-x64
and can reproduce on Windows 7, Windows Server 2008 R2, and Windows 8 Release Preview.
Anyone with TortoiseSVN 1.7.9 32-bit, do you have this issue?
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
I am using TortoiseSVN-1.7.9.23248-x64
and can reproduce on Windows 7, Windows Server 2008 R2, and Windows 8 Release Preview.
Anyone with TortoiseSVN 1.7.9 32-bit, do you have this issue?
Originally posted by Brian
Thanks flaviojs! Merged in [rev=16807].
Updating status to: Fixed
(it's more Fixed than it was before, but not as accurate as the 'svnversion' command or querying the SQLite db).
Thanks flaviojs! Merged in [rev=16807].
Updating status to: Fixed
(it's more Fixed than it was before, but not as accurate as the 'svnversion' command or querying the SQLite db).
Originally posted by Brian
Related: [bug=6798]
Related: [bug=6798]