Research for a Subversion plugin that works in windows and Linux.

[stahta01]

I am thinking that I have learned enough to try to create a Subversion plugin; it could take me many months to do it because I still have a lot to learn about wxWidgets, Code::Blocks and Subversion.

So, I wish to confirm that no one is already working on a Subversion plugin for windows and Linux?

Tim S

[MortenMacFly]

As far as I know, there is currently:
1.) a TortoiseSVN based plugin for Windows only (obviously) in the C::B forum
2.) a cross-platform approach done by Thomas ages ago: http://developer.berlios.de/projects/cb-svn/
The second one is rather old and AFAIK no longer seriously developed. But you should better ask Thomas about that (PM him). However - you can have a look into that project to gather a few ideas (maybe...)
Other development in that direction is not known to me.
BTW: Take in mind that C::B is already partially designed for version control systems (e.g. file images, file type enumerations etc.) which you might want to use/enhance.
To sum up: Go ahead! If you like then try to think really generic in terms of control systems, thus have a look at CVS when it comes to important interfaces... that would be my wish... ;-)
With regards, Morten.

[stahta01]

I know about both of then still looking at the old one, it looked the most advanced.

Tim S

[thomas]

The second one is rather old and AFAIK no longer seriously developed. But you should better ask Thomas about that (PM him).

Actually not developed at all any more. When it comes to it, that plugin will be rewritten from scratch. The plugin API has changed drastically since then, and a drastic change to replace wxExecute is in the closet for 4-5 months now, but will come. If I ever get a second PC with a Linux installation again, that is... might try to install Ubuntu on the notebook some day.

BTW: Take in mind that C::B is already partially designed for version control systems (e.g. file images, file type enumerations etc.) which you might want to use/enhance.

And bear in mind that this will change without notice

[Pecan]

I know about both of then still looking at the old one, it looked the most advanced.

Tim S

It would really be nice to have a SVN plugin. I use the MSW TortoiseSVN plugin constantly, and sorely miss an equivalent on linux.

Go for it...

If I can be of any help, just ask.

[stahta01]

OK, I plan to start work on this after I finish my Tax Paper work, this is due on 17 Apr in the US.
I plan to work on learning more about RapidSVN because I plan to base the plugin on it instead of TortoiseSVN.

The starting GUI will most likely be the same as MSW TortoiseSVN plugin. But I hope to upgrade it to a GUI like that of the OLD C::B RC2 SVN Plugin.

Tim S

[kelo81]

I know about both of then still looking at the old one, it looked the most advanced.

Tim S

It would really be nice to have a SVN plugin. I use the MSW TortoiseSVN plugin constantly, and sorely miss an equivalent on linux.

Go for it...

If I can be of any help, just ask.

If you use KDE, you may use the Subversion extension. It's a good replacement of tortoise, and comes with several distros.
I'm really happy that someone will start an SVN plugin again!!, plugins like this one will make Codeblocks the definitive IDE 

[Game_Ender]

Also, don't do anything to preclude its use on Macs.

[dmoore]

My two cents (since i've also thought about going down this path from time to time):
* As much as I hate to mention the competition, go and check out the version control in Eclipse. This will give you a good idea of what a well integrated version control system looks like.
* IMHO avoid dependencies on anything more than the command line svn/cvs clients in your plugin. GUIs like tortoise might save you time in the beginning, but your code will be more portable, more flexible and better integrated with CB if you write as much of the user interface in your CB plugin as you can.

[stahta01]

My two cents (since i've also thought about going down this path from time to time):
* As much as I hate to mention the competition, go and check out the version control in Eclipse. This will give you a good idea of what a well integrated version control system looks like.
* IMHO avoid dependencies on anything more than the command line svn/cvs clients in your plugin. GUIs like tortoise might save you time in the beginning, but your code will be more portable, more flexible and better integrated with CB if you write as much of the user interface in your CB plugin as you can.

Which Eclipse plugin are you talking about? Subclipse?

Tim S

[Game_Ender]

Yeah subclipse is very cool, it doesn't not require you to have subversion installed to work.  At most you should depend on the subversion libraries, calling the command line binaries is very hacky.

[dmoore]

Which Eclipse plugin are you talking about? Subclipse?

What I was talking about wasn't specific to any version control system (I was using CVS when I used eclipse) but the front end that eclipse provides to all of these systems. The subclipse screenshots give the idea (this was roughly the same for CVS)

http://subclipse.tigris.org/screenshots.html

Yeah subclipse is very cool, it does not require you to have subversion installed to work.

isn't that because subclipse IS a subversion client? (i.e. they've either ported svn client code or written it from scratch)

At most you should depend on the subversion libraries, calling the command line binaries is very hacky.

aren't the compiler, make and debug tools all command line binaries? isn't that hacky? :lol:

the main justification I have for using the command line binaries is that it will get a prototype up and running faster and make porting the code to CVS simpler. Converting to the API could be done at a later date (an optimization step)

IMO most of the effort needs to go into the GUI frontend and not rewriting the SVN client or interfacing with its API...

[Game_Ender]

Well if you notice the debugger plugin can get quite buggy, it would be much simpler to implement if there was a libgdb instead of having to waste all those cycles and effort parsing text.

I think you should do what the subversion developers recommend and use the libraries they provide (libsvn_client to be specific).  If you don't want to build directly on the API just use the already available C++ wrappers for the SVN api.  If you look at the API, you aren't "rewriting the client" you are using the well factored subversion project like it should be.

You can't honestly think creating a new process, running it, collecting stdout, and then parsing with handcrafted regexes is easier than a single function call?

[stahta01]

I plan to use Rapid svncpp API; first using an Tool Plug-in. Then working on a GUI Plug-in using the Rapid svncpp API. I figure that this is the easiest cross platform solution. Note, it will require that the users wait till the Rapid svncpp API is updated each time subversion is updated. Most of the time it does not matter, but sometimes the clients on an user machine must match or the lower version ones will not work.

http://rapidsvn.tigris.org/svncpp.html

[dmoore]

Well if you notice the debugger plugin can get quite buggy ...

that's at least partly because gdb itself is buggy (not to mention unwieldy). On the other hand, I imagine that GDB would be more stable if the bulk of it was written as an API

Anyway, I don't want to have a pointless argument about the pros and cons of APIs vs Command line wrappers and I apologise if my previous post caused offense. we're all friends here with the same objective: version control in code::blocks. Ultimately, I really don't care what interface to the SVN server is used. My preference for prototyping with command line hackery reflects my own prejudices.

What I really do care about is that the GUI frontend of the plugin is separated from the SVN interface, so that frontend can be accessed by other version control interfaces (be they command line wrappers or API calls).