Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

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

<< < (4/8) > >>

Game_Ender:

--- Quote from: dmoore on May 02, 2007, 03:13:28 pm ---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).

--- End quote ---

Now that is a topic worth discussion ;).  It is a much more difficult one as well because while many verioning systems are similar they have quite a few differences.  It's quite a design project to figure out the underlying API that abstracts away the differences between different systems and allows one GUI frontend to be used for them all.  It seems me the easiest way to do it would be make separate components out of the pieces that can be shared, like the diff viewer, conflict resolver, and repository browser, merge history browser.

Gagh:
You got a nice thread going here.

I'm really new here but just a few points after reading the rest of the thread. The points made about the way subclipse looks and feels is a valid one and I'd love to see something like it for C::B. A common interface to a number of commonly used SCM packages.

What you need is a map of all the functionality that is available in the current, often used SCM packages. Than you can provide a full API in the plugin and make a system that uses plugins or a factory with classes for all the different SCM packages. The specific SCM plugin or class could specify which functions it supports and then you can create the correct menus in C::B. What I'm getting at here is that you want to map all the add/remove/commit/lock/whatever options to a common interface within C::B.

Don't know how difficult it is to create a plugin framework, never have done it, but in my opinion it is the best option, as they can be written and maintained outside the main C::B SCM plugin. If you are going to use a class factory with a common interface to all the SCM packages, you need to write and maintain them.

Had a very quick look at the mentioned svncpp api included with the RapidSVN tool, but I don't like the looks of it. I think that you should keep the dependency list for the plugin as short as possible, i.e. only require the standard SCM client installation for that specific SCM system.

Svncpp calls into RapidSVN, so that needs to be installed for it to work. Just as the Tortoise plugin uses the commandline tool to call into Tortoise. I had to get the whole RapidSVN svn repository, because you are missing almost all the header files of you just get the svncpp part.

Well, big write-up, planned to make a short comment :P

Don't know what is planned atm for SCM support, just let me know what is happening, I might join in.

killerbot:
after the release of 1.0 I might also work on a general api for SCM.
I have for example a ClearCase plug-in (build/tested and used on Windows), but probably can be used with little modification on linux too.

Gagh:

--- Quote from: killerbot on May 22, 2007, 10:35:29 pm ---after the release of 1.0 I might also work on a general api for SCM.
I have for example a ClearCase plug-in (build/tested and used on Windows), but probably can be used with little modification on linux too.

--- End quote ---

Sounds nice, only question now is, when do we get 1.0?

Concerning my first post, is it hard to make a plugin framework within a plugin? As I stated in that post, to make a SCM plugin with a general API, adding the specific SCM as a seperate plugin to the C::B plugin would be the best approach. That way the C::B SCM plugin can be easily extended and you can load the specific SCM client module only when it is needed for the projects loaded in the workspace.

Only problem is that although I've been a paid programmer for 10+ years, I haven't seen the plugin problem before and don't even know how to approach it. But I guess that can be figured out and learned too. Guess that is is just a list with function pointers into the library that is loaded :D

Could you give a short description of your CC plugin? I mean what it does within C::B, like update the icons in the open file and project manager windows, extra context menu's etc.

I'll make a start for myself to get the hang of writing a C::B plugin. The CBTortoise plugin gave me a good idea how to do a couple of things.

I'll start with making the basic framework and api of the plugin, but will not create the pluggable SCM part, but just hook up a class to manage svn. All the SCM functions that should be available within C::B I'll try to figure out and and try to create them.

I'll build the svn client part against the svn client library, as that is imo the correct way. Another place to look at is the svn documentation.

Don't know if there is a better way to start work on it other then just start. We might be able to add something to the C::B wiki and use that space to give an overview of what we want to create.

I'll post a notice when I have something that I think is good enough to share with the C::B ppl.

stahta01:

--- Quote from: Gagh on May 22, 2007, 10:31:33 pm ---Svncpp calls into RapidSVN, so that needs to be installed for it to work. Just as the Tortoise plugin uses the commandline tool to call into Tortoise. I had to get the whole RapidSVN svn repository, because you are missing almost all the header files of you just get the svncpp part.

--- End quote ---

I am currently stuck, I had trouble just getting the Svncpp part of RapidSVN to compile because it depends on so many library. The APR (Apache Runtime) for example was giving me problems. I decided to put the project on hold while thinking about the fact of whether using svncpp is an good idea.

Tim S
 

Navigation

[0] Message Index

[#] Next page

[*] Previous page