The 14 february 2007 build is out.

[gjsmo]

I have a problem with this build. The tabs are broken. If you open enough tabs so that they cannot all fit, the arrow buttons become enabled. However, if you close enough tabs so that they can all fit, the buttons stay enabled because the tabs are not all put up on the "tab bar" - they are scrolled over even though they could go over. This happens all the time, and I would think it be easily reproducible. I am not sure what the bug is in, as I am not familiar with the C::B code, but I would think it has something to do with wxWidgets.

[Alturin]

Not sure if I understood it right, but did you try hitting the "<" arrow button? I have the same "problem" and it's solved by hitting it till all the tabs fill the bar. But it is a bit strange that that isn't done automagically.

[steveth45]

I'm running openSUSE 10.2.  This version of C::B loaded up fine a few times, but now it claims that the program is already running when I try to start up.  I can see no evidence of codeblocks running anywhere (top).  I even wiped the ~/.codeblocks folder, and it still thinks its already running.  I can't get it running to change the setting to allow multiple instances to run.  However, this is not the problem, since there is no "codeblocks" process running at all, even though it thinks there is.

[thomas]

When one has TortoiseSvn installed, there's no svn.exe. So bit ackward to add yet another svn client. So will revert temporarily back to previous method and wait till Thomas i back to fully fix the issue. It has worked in the past without pah adjusting and without extra svn installs, so probably should keep working like this ...

Ho ho, and back he is... hello again

It really cannot have worked without. If it did work, you had a Subversion executable and in your PATH and you did not know
Autorevision has always been and is still only calling svn.exe, so if that file does not exist or cannot be found (it obviously either has to be in PATH or in the same directory), it won't work, and it never worked.
It may be possible to call Tortoise as a backup solution if installed... in the past, this was awkward, but possible... not sure we should, though. Tortoise is not very much cross platform

I also have it in linux : "svn build rev 3609 (2007-02-15T15:43:11.509615Z) gcc 4.1.2 Linux/unicode"
Well more work for Thomas ;-)

Try applying my patch. It basically removes unwanted characters. But it doesn't fix any time zone related conversions. I hope there's not much work for Thomas. 

Yep, I'm aware of this issue. However, the point in switching to xml output was that I did *not* want to parse strings manually and figure out something that might be a date any more (which will always go wrong in some cases). Even though the timestamp output by Subversion currently seems to be (always?) ISO-formatted, we don't really know. It may be on some platforms, not on others, and it may change in the next revision (they made more drastic changes in the past).
In Chinese, Japanese, or Swaheli (or any other foreign language that I'm unable to decipher), date and time might as well be shown as 輸#式~戻?も (pretty much random characters without any significant meaning to me)
There is not necessarily a ':' or a '.' in a specific place (or at all), nor any arabic numbers.

It gets even more painful if you try to account for time zones. Time zone calculations are one of the most painful things on this planet, because there is no clean standard to how daylight saving times are implemented. Different countries have different formulas of determining the actual date, which differs by as much as 3 weeks around the globe, and they use different times, too.

Thus, I decided to go the easy way and trust that whatever Subversion outputs in the <date> tag is a properly formatted, properly localised string suitable to be used as a timestamp. No parsing, no tampering, no chance of anything going wrong. Not opening Pandora's box again

[Biplab]

Hi Thomas,

C::B SVN is in English. So why shall we bother about other languages?

Daylight savings have recently been changed in some countries (Sri Lanka, Australia, etc). So they made life bit more difficult.

So what have you decided on this problem?

Thanks & Regards,

Biplab

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

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

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;

      
And also quoting the first few lines of src/build_tools/autorevision/.svn/entries file.

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

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

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.

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

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

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?

[thomas]

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

Please don't. It were my fallback solutions that caused the problems why we use XML now. Although the intent was good, the idea was bad
We should keep our hands off parsing that stuff, seriously.

First we had people with other languages (2-3 French, 2-3 Turkish, and 1-2 Russian, but I think it applies to all) who could not get it to work, because their locale would cause the date to be written in some format that my fallback parser did not understand. That was bad enough already.

But then, even worse, the entries file format was changed, so my fallback implementation would not even work in English locale any more! Everybody who never bothered having Subversion installed properly (because the fallback worked nicely) started yelling "arg! the build is broken!" over night, when it really wasn't. It was just that the fallback did not work with the new entries format.

So, the new implementation uses Subversion's XML output format, which is hopefully standardised and immutable (or at least backwards-compatible) so we never see any such thing again.
I'm very much disinclined to use a custom-made hack and take the responsibility for keeping up with locales, time zones, and file format changes when there is really a clean, reliably working solution, only because some people don't want to install Subversion (or have it in path).
It's no problem really... those who don't want to install Subversion can use a source tarball (when one is available), or they will have "Revision 0".

I don't think requesting Subversion is an outrageous demand, either. Without Subversion, there is no way you can check out a the sources, anyway. No, please don't tell me there is TortoiseSVN and RapidSVN and whatever
Using Tortoise/RapidSVN or similar is always nasty tampering, which may work or may not (remember the _svn issue they had last year). Granted, it usually works really nicely (I use it all day, and I very very rarely see an issue), but it is not the one real, canonical thing.

[gjsmo]

Yes, hitting the < button works, but this should be done automatically. If there is enough room to see all the tabs, I want to see them!