SVNInside : development of another SVN plugin for CodeBlocks

[orel]

Thank you very much MuteSpirit for this bugfix and thank also for you comment, i also think that svn integration in Code::Blocks is a very useful feature!!
As you may have read, i am reorganizing the API once again to get SVNInside more robust. I am working on that but don't want to commit my work until i come with as much features as current version.

[ludug3r0]

Well.. Exactly the same problems darthdespotism had happened here too. Except that I'm with rev 4681. 
I couldn't see your plugin working yet but I'm anxious to see it working here.  I will keep trying to run it later.

Keep the good work! 

[darthdespotism]

Well.. Exactly the same problems darthdespotism had happened here too. Except that I'm with rev 4681. 
I couldn't see your plugin working yet but I'm anxious to see it working here.  I will keep trying to run it later.

Keep the good work! 

What Operating System are you on?

[ludug3r0]

Ubuntu 7.10

I can build the codeblocks source and the plugin too. Even the same erros in the post_build_step happende here. For the later I used dos2unix and it's now alright.

The only strange think that happened at compile time was two warnings about diferent -fpic settings between the Code::Blocks build files and the SVNInside build files... They happened at the plugin compilation.

Here is the warning that happens. It's the same warning in both times.

/home/rafael/Temp/CodeBlocks/src/include/sdk.h:12:26: aviso: /home/rafael/Temp/CodeBlocks/src/include/sdk_precomp.h.gch: created and used with different settings of -fpic

[orel]

Here is the warning that happens. It's the same warning in both times.

/home/rafael/Temp/CodeBlocks/src/include/sdk.h:12:26: aviso: /home/rafael/Temp/CodeBlocks/src/include/sdk_precomp.h.gch: created and used with different settings of -fpic

I really don't know what this is about? But as is said before, i am now working on a more robust version of SVNInside and my work is going on every day. So, if you can be a little more patient ,you should wait until i come with a new release, though i don't think it would resolve those warning you got!

Regards,
orl

[MortenMacFly]

though i don't think it would resolve those warning you got!

Don't worry, we can settle this easily then. The reason is most liekely a wrong parameter in the build setup... no prob. ;-)

[MortenMacFly]

...minor bug that causes a crash on exit on Windows Vista:
int void wxSVNTreeCtrl::OnProjectClosed(CodeBlocksEvent& event)
The line:
this->Delete(pLoadedPrj->GetId());
should better be inside the if (pLoadedPrj) (...) switch yard. Otherwise you are accessing a null pointer there possibly... ;-)
With regards, Morten.

[orel]

Thank you Morten for reporting me this bug, but the current code of SVNInside is nearly not at all the same as the one i commit to svn on assembla a long ago (some weeks). I am not commiting my current work until i come with a more stable version and with the minimum features one need. i am sure i will have some bugs but my api is now better designed.

Why i am taking longer than i thought is because i really had some big problems with ::wxExecute in asynchronous mode, and i decided for the moment to totally removes the asynchronous code, so all function calls are sequential and CB can be freezed when calling some svn commands taking a long time to return.

The problems i had with ::wxExecute called asynchronously had really no sense, sometimes everything worked like a charm, then next time i sent wxExecute a longer command line and it won't return, leaving my plugin anc CB hanging and freezing. I hope they will improve that or i will be obliged to do everything synchrously or maybe use another API for executing commands which is more stable, any ideas?

I am also looking ()at using subversion in a static or dynamic library to deal directly with the svn API : no command line, no pipes, more speed, more informations, more control. But sv is really a nightmare to compile and build on mingw, so it's not for tomorrow.

[MortenMacFly]

any ideas?

The issue you have described could be the "well-known" wxExecute bug that limits the command line to a () 255 characters. If you provide a longer command line you are corrupting memory without notification / exception. Thomas once discovered that issue but so far we were just lucky when creating compiler command lines. Thomas also worked on a cbExecute due to that that removes this (stupid) limitation. But AFAIK it is not yet finished.
With regards, Morten.

[eranif]

The issue you have described could be the "well-known" wxExecute bug that limits the command line to a () 255 characters. If you provide a longer command line you are corrupting memory without notification / exception. Thomas once discovered that issue but so far we were just lucky when creating compiler command lines. Thomas also worked on a cbExecute due to that that removes this (stupid) limitation. But AFAIK it is not yet finished.
With regards, Morten.

You got me curios there, so I went and read wxExecute source code (MSW), I cant seem to see the limitation you mentioned of 255 characters.
The command for wxExecute is of type of wxString, and it passed to ::CreateProcess() method like this command.c_str() - so no limitation here.

Maybe you are talking of Linux?
On Linux, for executing a synchronous commands, I dont use wxExecute, but this (it works very well on Linux & Mac):

Code

void ExecuteCommand(const wxString &command, wxArrayString &output, long flags)
{
#ifdef __WXMSW__
	wxExecute(command, output, flags);
#else
	FILE *fp;
	char line[1024];
	memset(line, 0, sizeof(line));
	fp = popen(_C(command), "r");
	while ( fgets( line, sizeof line, fp)) {
		output.Add(_U(line));
		memset(line, 0, sizeof(line));
	}

	pclose(fp);
#endif
}

EDIT: Forgot to mentioned, that my wx version is 2.8.4 on windows, 2.8.6 on Linux
Eran

[MortenMacFly]

I cant seem to see the limitation you mentioned of 255 characters.

That's why I placed the "" there. I don't recall exactly what the limitation was - but Thomas can tell.

Maybe you are talking of Linux?

It was on Linux, yes - definitely. (And I thought we are at Linux in this discussion as I saw /home/rafael/Temp/......?!). But IMHO this affected Windows, too. If not than this was my faulty assumption. ;-)

With regards, Morten.

[orel]

I cant seem to see the limitation you mentioned of 255 characters.

That's why I placed the "" there. I don't recall exactly what the limitation was - but Thomas can tell.

Maybe you are talking of Linux?

It was on Linux, yes - definitely. (And I thought we are at Linux in this discussion as I saw /home/rafael/Temp/......?!). But IMHO this affected Windows, too. If not than this was my faulty assumption. ;-)

With regards, Morten.

Not only linux, the problem i had with ::wxExecute which seem to deal with command line length sometimes, and something else the other times!!!??? happens to me on windows, so it may not be a platform problem but a wx one, IMHO!!

I am currently thinking of reimplementing my svniCommand classes with my old windows only implementation, someone could provide a working linux implementation, and the compiler will switch those regarding to the platform...

[darthdespotism]

When can we expect your new code? I'm very interested in this plugin

Trying to figure out why the plugin won't load for me I compared it to the Plugins provided with Codeblocks and noticed that these all provide an .la but SVNInside doesn't. So I tried to produce one for it but couldn't make it work up to now. Is this an necessary step for Gnu/Linux? Can anyone provide me help in how to produce one?

[orel]

For those of you who were waiting the new SVNInside code, i just updated the repository on Assembla with it. Sorry for linux users, i didn't update for the moment the linux CB project and the 'post_build_step' file.

Note that this is not a final release, and even a release at all, but this code is much robust than the old one.

Due to the fact i reverted to synchronous execution the svn commands, maybe CB can and will hang a little when loading a large project like CodeBlocks for example.

Many features are missing but the present ones are working.

Note also that for the moment repository needing a password/login to act on are not supported, but it is the next feature i am currently developing.
Try to play with it and continue giving me some feedback, advises, and patches thank you

I will make a longer post this weekend to explain the features this revision has

[darthdespotism]

After changing the #include in svniTreeItem from cbProject.h to cbproject.h I could build your plugin for Linux the usual Way (replacing the sources)

There seems to be no need to modify post_build_steps.

Patch for the above and Projectfile for Unix is in my attachment if it is useful for anyone.

I still can't load the plugin but that's no news. (Debian Lenny but was already there in Ubuntu Feisty)

[attachment deleted by admin]