Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Research for a Subversion plugin that works in windows and Linux.
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:
--- Quote from: stahta01 on April 25, 2007, 09:27:06 pm ---Which Eclipse plugin are you talking about? Subclipse?
--- End quote ---
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
--- Quote from: Game_Ender on May 01, 2007, 07:27:26 pm ---Yeah subclipse is very cool, it does not require you to have subversion installed to work.
--- End quote ---
isn't that because subclipse IS a subversion client? (i.e. they've either ported svn client code or written it from scratch)
--- Quote --- At most you should depend on the subversion libraries, calling the command line binaries is very hacky.
--- End quote ---
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:
--- Quote from: Game_Ender on May 02, 2007, 05:43:56 am ---Well if you notice the debugger plugin can get quite buggy ...
--- End quote ---
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).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version