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).

[Game_Ender]

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).

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

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]

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.

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

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]

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.

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
 

[MortenMacFly]

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.

I "only" tried to compile RapidSVN once and had the same problem. I couldn't resolve all dependencies (thus get all the libs to compile and/or download them somewhere)... It's terrible.
With regards, Morten.

[Gagh]

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.

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
 

Well, for svn I'm going to try to build the example minimal_client given in a post I found.

Seems there is a way to get client libs and headers in what looks like a client development pack. Must say it is hard to find any info on the subversion site at tigris, but will try to locate some good info on how to use the prebuild libraries and headers.

But I guess that building the subversion client libraries is outside the scope of the basic SCM plugin for C::B.

I have a basic layout that I'm working on atm for adding the menu's and configuration within C::B. The code that creates the menu's query a class that specifies what options are available for the scm type and then displays only the options that are available. The function that is called from the menu then should call the specific client code with a filename and probably some extra configuration info.

My main aim atm is to learn the plugin environment of C::B and figure out if we might be able to modify icons in the project view and open file view to provide status information. What I also need to figure out is how we can create a window in the Messages panel and show progress info when the user activates one of the menu options.

I guess that mandrav might be able to provide some info on that, or at least point where we can find out how to do those modifications.

I have attached a screenhot of my current settings panel, just for fun. (Yes, I stole the icons )

Update:
I must be blind! In the downloads section of subversion the development archives with prebuild libraries can be easily found. It even includes documentation.

First version:
For those that want to have a laugh, got an initial version in svn that I use for local development. Doesn't do a lot more than crash your C::B

Going to add Tortoise to it for a quick fix and example how you can add support for a specific SCM system. It will be based on the nice CBTortoiseSVN from thomas.

After that it will be a hard look at native svn support through the svn client api. But you need apr/apr-util/apr-iconv and neon builds with mingw to be able to build the svnclient library. They even recommend TortoiseSVN to get the sources of apr if you want to build on MSW on the apache apr site

The binary downloads from the subversion site are static libs for MS VC, couldn't get a minimal_client they posted on the subversion site as example linking against them with mingw.

[attachment deleted by admin]

[Gagh]

Well, it has been quiet here in my absence....

Just back after a few weeks away in foreign parts for my boss, so nothing has been done on my plugin. Just dropping a note that I'm still working on it. First thing is figuring out what I have written, as I've not seen the code for about 2 months.

[dmoore]

Gagh: take a look at the fileexplorer in my cbilplugin project (follow the link in my Sig for win32 binaries or access to the SVN). this control might provide you with a good base for SCM UI (because all SCMs operate on the principle of maintaining a directory under version control).

[JGM]

Great! I was thinking on making an svn plugin multiplataform too. Nice to read this.

[dmoore]

I played around with parsing the SVN stat command to provide decorators for files (but not dirs) in the file explorer of my newly renamed Shell Extensions plugin. I'm using the default CB version control icons, but if someone wants to contribute prettier graphics, you know the drill...



checkout from the cbilplugins svn (link to project page in my sig). i haven't tested on windows and it runs pretty slowly for now.


PS: has anyone tried bazaar? In my short testing period, it leaves SVN in the dust...

[mariocup]

Hi dmoore,

cool. I will test the new features in the plugin. What about using TortoiseSVN icons?

What program do you use to make the icons and what is the original format (svg)? I will have a look at it and perhaps at the week end I will spend some time on making new icons.

[dmoore]

mario: the icons are somebody elses handy work -- they were already in share/codeblocks/images. I won't use the tortoise icons unless the license allows it. if you do make icons, make the decorators a separate image from the file/folder icon and then just overlay them in the gimp or something.

I don't think you will have success on win32. it looks like svn stat reports the relative path on win32 (it reports the full path on linux). I'll fix sometime today.

[yop]

PS: has anyone tried bazaar? In my short testing period, it leaves SVN in the dust...

I have tried pretty much everything in distributed SCMs and my advice is to try Mercurial (hg). It 's blazing fast, python powered and user friendly. Even Linus had a few good words for it (which is rare) and it's the only one he compared to git (his own, used for the kernel, also really fast SCM). I was working with darcs for quite a while, then tried out bzr, git, monotone and stuck with hg. Oh and any distributed system leaves the centralized ones in the dust.

[dmoore]

I have tried pretty much everything in distributed SCMs and my advice is to try Mercurial (hg).

my impression was bazaar is being more actively developed (it has Shuttleworth's $ behind it after all). I'm only using bzr for personal use, so my needs are modest. I'm loving the option to make offline commits and bind/unbind a networked repository...

for giggles, if you send me the output of some sample "hg status" commands I'll implement the file decorators for it as well. (I just implemented the decorators for bzr and fixed the svn win32 issues). EDIT: don't worry hg was easy to download and as easy to use as bzr

[yop]

I won't argue, both are excellent tools. It's a matter of taste I guess. Offline commits are a dream, especially if  you travel a lot like me and have to do stuff on the road. Anyway I 'm attatching some samples:

1. nothing in the repository
2. all inside, not commited
3. all commited, main.cpp changed Makefile.Release deleted

When there are no pending changes hg status reports nothing back.

[attachment deleted by admin]

[dmoore]

done. let me know if i have all the icons straight. EDIT: looks like ignored files aren't shown by default, will have to come up with a workaround.

note that the hg, bzr and svn commands are all hardcoded and must be in the path. it's also slow as hell to expand directories right now as i haven't attempted to optimize anything. ideally I should tap directly into the c/python api's of each VCS...

[dmoore]

has anyone tested the latest (or a recent) revision of my ShellExtension plugin to see if SVN/Mercurial/Bazaar(/CVS -- it has major issues) file state images appear correctly in their FileExplorer? If so, feedback is needed:
* Is this feature of the plugin useful? (I realize some people would rather work in the projects pane, but working at the filesystem level has its benefits)
* what bugs/issues do you have?
* what additional features would you like to see?
* I'm hoping to move large chunks of the plugin into an api so people can plug in their own filestate population routines to support arbitrary VCS (or SCM if you prefer) using either the VCS APIs or command line tools.

Keep in mind that this is just one tool of the suite of tools required for a fully featured VCS gui (e.g. we need conflict resolution tools, revision browsers, diff viewers etc - not all of these need to be native in CB, but they should be launchable from CB)

(PS: The latest rev lets you switch on or off which VCS are polled to speed things up a bit, but more performance improvements coming soon.)

[darthdespotism]

Last time I looked for this there wasn't much but i seem to have missed a lot.

I tried to build and install the ShellExt Plugin on my Ubuntu Box and I did get it to compile correctly, but I can't install it as I don't get a .cbplugin file. I tried to look for this in the wiki but didn't found anything useful.

Can you tell me how to install the Plugin? I do have the .zip and the .so

[dmoore]

Can you tell me how to install the Plugin? I do have the .zip and the .so

not having ubuntu in front of me right now to verify, it should be enough to just copy the .zip and .so to /usr/share/CodeBlocks and /usr/share/CodeBlocks/plugins, respectively (assuming you have built ShellExt against your hand compiled CB and that I have given you the correct locations )

[darthdespotism]

OK if this should be enough than maybe not being able to start or use this plugin is caused by this error Codeblocks mentions while starting. I should look out for the logs ...

btw: the locations are correct but should be spelled in lowercase

EDIT://
BugReport:
For this Plugin to work with Linux you need to make the .zip lowercase just as the .so.

When doing so it is found by Codeblocks. No functionality tested yet