SVN plugin

[thomas]

It is not surprising that it does not work with latest CVS -- it *cannot* work.

The plugin still needs to be rewritten to reflect the ConfigManager API changes which are new in HEAD, sorry.

That's what you get when you change an existing API, but better now than later

[Urxae]

It is not surprising that it does not work with latest CVS -- it *cannot* work.

The plugin still needs to be rewritten to reflect the ConfigManager API changes which are new in HEAD, sorry.

The changes for that are actually fairly trivial and included in my patch above. (though it includes a lot of other stuff as well, precompiled header etc.)
Note that I haven't actually checked if that part works, just that it compiles. Don't see any reason it wouldn't, though. The patch is more of a temporary measure until a new 'official' version comes out (or is merged to trunk).

[MortenMacFly]

Thanks to the patch of Urxae I was able to compile and integrate the SVN plugin into the current SVN-HEAD of C::B. It looks great and I am currently playing around with it a little and would like to point at the following:
- It's a bit confusing that the OK/Cancel buttons are in reverse order. I believe OK should always be on the left side (as it is on the default message dialogs).
- I have TortoiseSVN installed but the plugin does not detect it. I can setup the path to CVS, SVN - is there a reason why not for TortoiseSVN?

Morten.

[mandrav]

Thomas will be back after November 30th, so you 'll have to wait a bit for an authoritative answer

[Urxae]

Hmm, it seems my patch no longer works with the latest SVN version of C::B...
Looks like a nullpointer-dereference on startup. :?

[MortenMacFly]

Hmm, it seems my patch no longer works with the latest SVN version of C::B...

...it works for me. The only thing I have changed was converting the project file to use the NEWBUILD method.
At which operation does it crash exactly?

Morten.

[mandrav]

Hmm, it seems my patch no longer works with the latest SVN version of C::B...
Looks like a nullpointer-dereference on startup. :?

Hmm, nothing was changed during the migration...

[thomas]

There and back again

- It's a bit confusing that the OK/Cancel buttons are in reverse order. I believe OK should always be on the left side (as it is on the default message dialogs).

Windows has no standard for this. Or maybe it has, but the Microsoft developers do not follow it, either. Most of the time, they put the affirmative button to the left, but sometimes they don't (look at the error reporting dialog, msi, most wizards, automatic updates, or the firewall dialogs, for example).
I have been doing things according to Apple's "Human Interface Guidelines" since 1992. These tell you to have the affirmative button to the right, the cancel button next to it, and any other button (like "Reset") separately on the left. Whatever is "correct" according to Microsoft, I don't know, and I don't care. :lol:

I have TortoiseSVN installed but the plugin does not detect it. I can setup the path to CVS, SVN - is there a reason why not for TortoiseSVN?

It should actually find it either from the registry or by searching the "normal" install location. Strange thing it does not.
The reason why you cannot configure it in the settings is that there is CVS. Actually you could configure Tortoise back in the very old days, but then I did not want to make the settings dialog too complicated when CVS was added. The next release will need so many changes that it will probably need to be completely rewritten anyway. Tortoise will be configurable again by then.

[MortenMacFly]

There and back again

That's great! Thanks for your answering.

Windows has no standard for this.

I agree. What I ment as a "standard" is the order as presented if you trigger a Ok/Cancel message box in wxWidgets. There (usually) Ok is on the left and Cancel on the right. However - I think a bigger "confusion" was because most of the other dialogs in C::B are different. So I vote therefore for a solution to be the same inside C::B... Not neccesarily related to your plugin but in general. Maybe you agree on that. (It's not a big deal, anyway...)

Tortoise will be configurable again by then.

That would be helpful to me. I'm looking forward to the next release. Especially since C::B itself is using subversion... that's a pretty good testcase (you can imagine)...

Thanks for the hard work...

Morten.

[RJP Computing]

I am tring to compile the patch but I can't get it. Can somebody please post the compiled patched version.

[Urxae]

I am tring to compile the patch but I can't get it. Can somebody please post the compiled patched version.

I'd do that, but unfortunately it currently crashes C::B on startup for me, so I don't think it'd be much use .

[RJP Computing]

I'd do that, but unfortunately it currently crashes C::B on startup for me, so I don't think it'd be much use .

Well I would love to try it out. I only use svn for all my projects so I really would like to use the plugin.
Thanks

Thomas,
Are you still developing this? With the move of C::B to SVN this plugin is crutial in my opinion.

[Urxae]

Well, here's my compiled version for Code::Blocks SVN (rev. 1447 + my local modifications).
If it crashes with another error than I got (an access violation) you might want to try rebuilding Code::Blocks after applying that to a freshly checked-out copy. (Just in case there was a binary incompatability with my modifications, either to the source or the command-line options).
I also included my patch for the svn plugin again, just in case you want to try compiling that yourself again...
Oh, and I use wx2.6.1, so if you're using another version it probably won't work.

...

Damn, the max attachment size is 128 kb . I've uploaded it here.

[RJP Computing]

Well, here's my compiled version for Code::Blocks SVN (rev. 1447 + my local modifications).
If it crashes with another error than I got (an access violation) you might want to try rebuilding Code::Blocks after applying that to a freshly checked-out copy. (Just in case there was a binary incompatability with my modifications, either to the source or the command-line options).
I also included my patch for the svn plugin again, just in case you want to try compiling that yourself again...
Oh, and I use wx2.6.1, so if you're using another version it probably won't work.

...

Damn, the max attachment size is 128 kb . I've uploaded it here.

Thanks I gave it a try and now it says I have version 1.5 of the SDK installed but I need version 1.6. Can I just get the latest source for C::B and use the 'SDK' directory?

[Urxae]

Thanks I gave it a try and now it says I have version 1.5 of the SDK installed but I need version 1.6. Can I just get the latest source for C::B and use the 'SDK' directory?

No, you need a newer version of Code::Blocks to use it. The SDK version was raised to 1.6 in revision 1422 (Dec 2nd), you'll need a version after that. If you're dependant on Ceniza's and Therion's builds you'll have to wait, neither has put up a new build since then.
Looking some more at their builds, they both seem to be using wx 2.6.2, so my binary probably won't work with them anyway.