Building git repo

[BlueHazzard]

Hi,
every time i build c::b from a git repo (https://github.com/obfuscated/codeblocks_sf/tree/no_ui_sdk) i get

Code

svn: E155007: '[...]\src' is not a working copy

and autorevision starts a huge tree of git/perl executables. I don't know what exactly they are doing but this operation is taking a huge amount of time, every time i build c::b (and this is are a lot of times lately)

for the moment i deleted the command from the pre-build steps, but this gives me a diff for the project file and i wanted to avoid this.

So my questions are:
* What does this executable
* Is there a way to cache the results, so that it hasn't to rescan every time i build c::b?

greetings

[oBFusCATed]

Is this on windows? On my linux it doesn't take much time.
The source for this executable is in build_tools/autorevision/autorevision.cpp probably you can modify it to fix this problem and then provide a patch.

[BlueHazzard]

yes windows -.-
here it takes at least 15min. The slowness seems to be in git svn info. I will look into it...

[stahta01]

yes windows -.-
here it takes at least 15min. The slowness seems to be in git svn info. I will look into it...

What version/build of git for Windows are you using?

I am trying this myself on Windows and forgot where I found the git svn I found that worked.
(Had hard drive semi crash on me.)

Tim S.

[BlueHazzard]

1.8.1 from msys

[thomas]

The issue is that you are trying to build a non-supported source tree, if you ask me.

The autorevision tool does nothing but call subversion to find out the current revision of the checked out sources. It then places the value as an integer literal and as a character constant into a file. If you can figure out correctly what svn revision your checked out copy refers to, you can edit that file by hand and put in the respective number.

The reason for the existence of this tool is that once upon a time there was the desire to have the revision number prominently displayed, since whenever someone reported a problem and was asked what revision they used, the answer was uniformly: "Uh, what? I have no idea... where can I see this?"

Now the thing is, git doesn't have revisions (or does it, in the mean time?), so it's kind of hard for subversion to find it the current revision. I don't see how you could patch the tool in a meaningful way either because not only is a git commit .... what is it called, checksum (?) like  773dea65156909838fa6c22825cafe090ff8030 not valid, and unwieldy, and it also probably won't play well with the layout on the start page.

[ollydbg]

I use git-svn (portablemsysgit+tortoisegit under Windows)for half a year, I don't have such issue. But obviously I don't put the bin folder of msysgit in PATH, so my build C::B always show a "0" in the revision dialog.

Basically, the msysgit command can only be used in a bash shell (in msys prompt), not the normal Windows command line.

[oBFusCATed]

This is how we do it for the autotools revision number:

Code

elif git log --max-count=1 >/dev/null 2>&1; then
        echo "Using 'git log --graph' to get the revision"
        REV=`git log --graph | grep 'git-svn-id' | head -n 1 | grep -o -e "@\([0-9]*\)" | tr -d '@ '`
        LCD=`git log --date=iso --max-count=1 | grep -o -e "Date: \(.*\)" | cut -d ' ' -f 2- | sed 's/^ *//' | cut -f -2 -d ' '`
else

What this does is to find the last svn commit and extract the svn rev from its commit message.
Probably, it can be done the same way in the autoversion tool, too.

[BlueHazzard]

Hi.
i have found a possible speed up for this problem. If i use  "git svn find-rev" instead of "git svn log" then i have a speed up of 6000%

patch is attached

there is only a different date format if you use the git version, because i can't modify the git date output to look like the svn output...

greetings

ps. this is again a git patch...
pss. Am i really the only one with the speed problems of "git svn log" ? git version 1.8.4.msysgit.0  (it doesn't work from msys as from the cmd)

[edit] The patch had a view bugs...

[ollydbg]

Hi.
i have found a possible speed up for this problem. If i use  "git svn find-rev" instead of "git svn log" then i have a speed up of 6000%

patch is attached

there is only a different date format if you use the git version, because i can't modify the git date output to look like the svn output...

greetings

ps. this is again a git patch...
pss. Am i really the only one with the speed problems of "git svn log" ? git version 1.8.4.msysgit.0  (it doesn't work from msys as from the cmd)

[edit] The patch had a view bugs...

Follow the instructions of README.portable file under PortableGit-1.8.5.2-preview20131230
I simply add the folder: E:\code\msys\PortableGit-1.8.5.2-preview20131230\cmd to the PATH. (there is a file named git.exe in this folder)

I'm using a git-svn mirror(I use git-svn to checkout C::B svn about half year ago, not the full svn revision), I found the trunk code of autorevision.cpp works fine, it can detect the correct svn revision number my local git branch based, but with your patch, I get the svn revision number 0.

I don't see much time difference before and after your patch.

[dmoore]

I am seeing this on my Ubuntu 13.10 machine. Really odd!

[BlueHazzard]

does the patch work?

[Jenna]

does the patch work?

The patch can not work, if the last commit is just a local one, because in this case the hash is not related to an svn revision.

[BlueHazzard]

yes. then in prints out 0
but if you have a local commit, then you don't have a valid svn number... so...

[edit]
but the real question is: why is it on some machines slow (what is somehow expected, because it has to scan the whole tree) and on other so fast...

greetings

[dmoore]

Annoyingly the delay isn't even consistent on my Ubuntu machine. Sometimes it's slow, sometimes not.

[EnterTheNameHere]

Hi,
every time i build c::b from a git repo (https://github.com/obfuscated/codeblocks_sf/tree/no_ui_sdk) i get

Code

svn: E155007: '[...]\src' is not a working copy

and autorevision starts a huge tree of git/perl executables. I don't know what exactly they are doing but this operation is taking a huge amount of time, every time i build c::b (and this is are a lot of times lately)

I use git-svn (portablemsysgit+tortoisegit under Windows)for half a year, I don't have such issue. But obviously I don't put the bin folder of msysgit in PATH, so my build C::B always show a "0" in the revision dialog.

Basically, the msysgit command can only be used in a bash shell (in msys prompt), not the normal Windows command line.

I'm building Alpha's cc_interface git branch and this issue appears there too. I found out from autorevision.cpp that the command "git svn info" (line 160) causes this long operation, or maybe even infinite operation, I terminated autorevision.exe after 20 minutes. I tested it in msys prompt too, but it's the same behavior.

As a quick fix I just removed the pre-build command from sdk build and provided custom autorevision.h with "const unsigned int svn_revision = 0;" etc. Can this cause any issues for Code::Blocks and it's plugins, or is the svn revision only used to display it/create changelog?

[oBFusCATed]

As a quick fix I just removed the pre-build command from sdk build and provided custom autorevision.h with "const unsigned int svn_revision = 0;" etc. Can this cause any issues for Code::Blocks and it's plugins, or is the svn revision only used to display it/create changelog?

No, but it should stay away from official svn trunk:)

[ollydbg]

@ EnterTheNameHere
It works fine here, you can read this post: http://forums.codeblocks.org/index.php/topic,18635.msg128345.html#msg128345

[jondo]

[...]
I don't see how you could patch the tool in a meaningful way either because not only is a git commit .... what is it called, checksum (?) like  773dea65156909838fa6c22825cafe090ff8030 not valid, and unwieldy, and it also probably won't play well with the layout on the start page.

It is usual to abbreviate this Git commit hash to the first e.g. 6 characters: "773dea". This carries enough info to identify the revision and is short enough to replace any SVN version.
To reduce the effect that such commit hashes do not carry any time information, it makes sense to increase the version number more often (e.g. via semantic versioning) and to display a build date.

[oBFusCATed]

Patches welcome. But keep in mind that the official VCS is still SVN!