User forums > Nightly builds

The 14 february 2007 build is out.

<< < (8/9) > >>

killerbot:
Hello Thomas,

Nice to see you are back.

Well really it has worked in the past, really really. I build CB on windows on 2 different machines (and in the past on 3). All of them have TortoiseSvn installed, none of them svn.exe. Really I never ever added svn.exe. And all of them were able to put the svn rev number in the build (proofed by the older nightly builds). But now all of them give the "0".

I will do on my laptop a test, by just reverting the autorevision.cpp to see what happens (hopefully it works together with the .h file being moved/created in another location).

killerbot:
@Thomas.
I looked at the old autorevision.cpp and I know why it used to work. Partly you are correct the QuerySvn() never worked when there was no svn.exe, but the old code would try ou the fallback mechanisms through ParseFile()

Those 2 fallbacks are gone. I will put hem back locally on my machine and see if things are ok again, if so I would suggest, if you agree, to bring them back. I know it's ugly and hard to maintain code, put it is better then nothing.

Biplab:
Hi Thomas,

Killerbot is correct. I can confirm his finding. In my PC, svn was not in path, but there used to be no problem in compiling and the revision number was always printed properly. I just had a look into older autorevision.cpp file.

The following line was responsible in providing the correct revision number even without using svn.

--- Code: ---    QuerySvn(workingDir, revision, date) || ParseFile(docFile, revision, date) || ParseFile(docFile2, revision, date);
--- End code ---

Once the QuerySvn() failed, ParseFile() was called and it's parameters are as follows.


--- Code: ---    string docFile(workingDir);
    docFile.append("/.svn/entries");
    string docFile2(workingDir);
    docFile2.append("/_svn/entries");
--- End code ---

So basically autorevision was using <WorkingDir>/.svn/entries file to provide correct revision number when svn was not in PATH. I'm quoting the following code from old autorevision code.


--- Code: ---        while(!inFile.eof() && c < 6)
            inFile >> token[c++];
        revision = token[2];
        date = token[5].substr(0, strlen("2006-01-01T12:34:56"));
        date[10] = 32;
--- End code ---
      
And also quoting the first few lines of src/build_tools/autorevision/.svn/entries file.


--- Quote ---8
dir
3624
https://biplab@svn.berlios.de/svnroot/repos/codeblocks/trunk/src/build_tools/autorevision
https://biplab@svn.berlios.de/svnroot/repos/codeblocks
2007-02-13T11:28:07.805641Z
--- End quote ---

So third line gives revision number and the 6th one is giving date & time.

I compiled and ran old autorevision in two places, once in Desktop and next in src folder. I'm quoting error of one case (svn not found error is present in both the cases)-

--- Quote ---C:\Required\cbsource\src>build_tools\autorevision\autorevision.exe +int +t . autorevision.h
'svn' is not recognized as an internal or external command,
operable program or batch file.
--- End quote ---

And the file content is as follows.

--- Code: ---/*3624*/
#ifndef AUTOREVISION_H
#define AUTOREVISION_H

#define SVN_REVISION "3624"

#define SVN_DATE     "2007-02-20 10:43:54"

namespace autorevision
{
const unsigned int svn_revision = 3624;
}

#endif

--- End code ---

When I run autorevision in Desktop, following file is generated.

--- Code: ---/*0*/
#ifndef AUTOREVISION_H
#define AUTOREVISION_H

#define SVN_REVISION "0"

#define SVN_DATE     ""

namespace autorevision
{
const unsigned int svn_revision = 0;
}

#endif
--- End code ---

In newer autorevision this ParseFile() function has been removed which is creating problem if svn is not available in PATH.

Regards,

Biplab

killerbot:
when re-adding the 2 ParseFile() methods, all works well again.
@Thomas : do we add them again ??

For tonights nightly I will build with my private copy of autorevision.cpp

Alturin:
I'm thinking, why not add them? I mean, what's the worst thing that could happen? A wrong revision number being shown?
Wouldn't a wrong revision number in the theoretical case SVN decided to change it's .svn directory structure be better then the actual case of always a '0' as revision number?

Navigation

[0] Message Index

[#] Next page

[*] Previous page