Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: thomas on June 07, 2005, 07:38:24 pm

Title: SVN plugin
Post by: thomas on June 07, 2005, 07:38:24 pm
I am working on a Subversion plugin right now, still fighting alternately with the SDK and wxWidgets.
Currently, the plugin works only as much as providing "update" and "commit" for HEAD on either single files or project directories via right-click on the project manager and progress feedback in a SimpleTextlog. Not quite finished, as you must do stuff like import and  checkout with Tortoise, but hey, it is a start ;)
If wxWidgets is not giving me too much of a hard time, then the plugin should be "usable" until the end of the week.

Once everything works fine for svn, it should not be too hard to include cvs as well. I have always avoided using cvs, so my knowledge on that particular thing is limited, but as I understand it, svn syntax is pretty much the same (as svn is meant to replace cvs). Therefore, cvs support might be as easy as chaning three letters? :)
Title: Bounty: CVS plugin
Post by: rickg22 on June 07, 2005, 08:08:37 pm
Cool! Thanks a lot!! :D

Please keep us informed.
Title: Bounty: CVS plugin
Post by: mandrav on June 07, 2005, 08:47:09 pm
Quote
Therefore, cvs support might be as easy as chaning three letters?

Not exactly, but close ;)

Yiannis.
Title: Bounty: CVS plugin
Post by: rickg22 on June 08, 2005, 12:10:30 am
Maybe you could add a special case for when tortoise is installed, and call it instead. :)
Title: Bounty: CVS plugin
Post by: thomas on June 09, 2005, 06:23:32 pm
Quote from: rickg22
Maybe you could add a special case for when tortoise is installed, and call it instead. :)


It never occured to me one could call tortoise from a command prompt (don't we install it to avoid a shell), but hey, that is an ingenious idea. It is actually intended that way, and works like a charm.

For Windows users, that is surely the way to go, it will be hard to make the Interface as good as or better than tortoise is already, so why not use it.
Sadly, tortoise is not precisely available on Linux, so I guess it still must have a fallback ;)
Title: Bounty: CVS plugin
Post by: rickg22 on June 09, 2005, 07:33:15 pm
In fact I wanted to write said plugin, but never had the time. I spoke with one of the tortoise devs, and they told me that the file in question was tortoiseact.exe. But first get the CVS going, later we could do the tortoise stuff.

Still, I'd like the menu to look like Tortoise's: Like "update","update special", etc.
Title: Bounty: CVS plugin
Post by: tiwag on June 09, 2005, 11:50:01 pm
Tortoise CVS as well as WinCVS (http://www.wincvs.org)
are using cvsnt (http://www.cvsnt.org)

i've installed a separate version of cvsnt on my harddisk and have Tortoise
as well as WinCVS working in parallel, using the cvsnt version.
it's easy to configure, both cvs GUI frontends have some option dialogs for this.

the cvsnt version comes with an excellent documentation and the commandline tool cvs.exe
can be used in parallel to the GUI cvs stuff,
sometimes small batchfile scripts are more convenient than all that right-click menu stuff.

[addendum]
what's svn ? can someone pass a link please ?
Title: Bounty: CVS plugin
Post by: rickg22 on June 10, 2005, 01:45:25 am
SVN: SubVersioN. http://subversion.tigris.org/ - it's a software similar to CVS.
Title: Bounty: CVS plugin
Post by: tiwag on June 10, 2005, 02:18:16 am
Quote from: rickg22
SVN: SubVersioN. http://subversion.tigris.org/ - it's a software similar to CVS.


@rick: thanks for the link !

svn looks promising, no more broken repositories if they tell us the truth...

Quote from: the following is taken from: Version Control System Comparison (http://better-scm.berlios.de/comparison/comparison.html)
Support for atomic commits means that if an operation on the repository is interrupted in the middle, the repository will not be left in an inconsistant state. Are the check-in operations atomic? Are the check-in operations atomic, or can interrupting an operation leave the repository in an intermediate state?
Title: Bounty: CVS plugin
Post by: David Perfors on June 10, 2005, 08:48:34 am
svn is very promising indeed, only I don't get it working very easily :) (I think I want to go to fast...)
Title: Bounty: CVS plugin
Post by: mandrav on June 10, 2005, 08:49:23 am
Quote
svn looks promising, no more broken repositories if they tell us the truth...

Oh, they are :D
I 've been using it for my personal projects for over a year now and it's much better than CVS.

Yiannis.
Title: Bounty: CVS plugin
Post by: upCASE on June 10, 2005, 11:25:25 am
Hi!
Right, SVN really rocks. We're using it in the company I'm working for and skipped to it after using CVS. No problems yet (exept those we already had with CVS, like being to stupid to commit or failing to resolve conflicts :D)
Title: Bounty: CVS plugin
Post by: thomas on June 22, 2005, 06:06:01 pm
Just a little update in case you think I have unexpetedly died  :P
Due to a few pecularities, it takes longer than I had ever expected, but it seems like the end is getting a little closer.

So, here is a little status report to let you know what works (and what does not) so far:

checkout
- works, still needs to have a MRU added
- auto-open project not implemented yet

auto-discover svn and tortoise
- works fine on WIN32, should work on Linux too

import tortoise repo MRU
- I almost committed suicide on that... another time maybe

import
- not yet

update file / update project (from context menu)
- works fine including revisions, but does not handle conflicts yet

commit file / commit project (from context menu)
- works fine, but does not handle conflicts yet

branch
- works if Tortoise is installed
switch
- works if Tortoise is installed
merge
- works if Tortoise is installed
Tortoise support is still a bit awkward as it will currently only run with a nasty hack. I have not figured why, though.
The issue is that if I call it using wxExec, it is cold as a dead fish. This was quite surprising and cost me a lot of time.
The workaround is to start cmd /C to call tortoise, this works, but I have no idea why. Maybe a wxWindows issue?


auto-add nonversioned files (configurable)
- works

auto-add when adding to project (configurable)
- works

auto-delete when deleting from project
- had planned that, but not sure one would really want this

auto-handle missing files
- not yet

svn properties browseable in context menu
- Yes! Particularly proud of that, this is one thing I actually got better than Tortoise has it  :)

add new file properties / edit
- almost :)

svn delete from context menu
- works

svn move from context menu
- Uhhh... (yes... although it occasionally crashes the project manager...
have not figured how to remove a file and re-add it properly, multiple build targets don't really make it easier)

revert
- Uhhh... this *should* work, although it occasionally caused a "cannot create file" error, so I postponed it for now. Maybe the test repository is just screwed up...

log/history browser
- nothing yet

diff
- nothing yet

resolve
- nothing yet

lock
- locks? locks are evil.

cleanup
- not yet
Title: Bounty: CVS plugin
Post by: rickg22 on June 22, 2005, 06:15:04 pm
Hmmm I wonder if having "the project" intermingled with cvs/svn is a good idea - i mean, shouldn't the versioning system take care of what files belong to a module?

Just a suggestion.
Title: Bounty: CVS plugin
Post by: thomas on June 23, 2005, 12:51:03 pm
You don't need to turn it on if you don't want it :)
Personally I am a lazy bastard, and I expect files added to revision control even when I copy them into the folder (why should I bother if the computer can do the work). This is arguably wrong, but in my opinion, if something is not explicitely caught by an ignore pattern, then it either should be controlled or it should not be in the project directory.
Other people feel different of course, and many have a problem with the computer doing things behind their back. Certainly understandable. You're free to choose, however.

The plugin runs 'svn status' when opening the project and before committing just like tortoise does, too (*). While tortoise will ask you "add these?" every time, you can tell the plugin to just do so silently.
The "add when added" function is much like tortoise's "svn copy here" command.

Another thing: I have not found anything like ProjectIsClean() in c::b. Is there anything like this except walking through all buildtargets? There is cbProject::GetModified(), but that only barks when files have been added or deleted, not when they're modified and saved.
The thing I have in mind is some sites have a policy like "only commit a revision that builds without errors, or you are publicly humiliated and ostracised for seven generations".  
For these, and to save on aspirin, an option "require clean build before commit" might be worth consideration.


(*) this is an understatement. Actually  'svn status' is called an awful lot of times. This sounds like mega-overhead, but it is actually quite fast and it does not need network (on my machine 20-100 ms). The gains are huge: BuildModuleMenu, for example, builds a custom menu for every file, only showing 'commit' if the file is actually modified, and listing file properties ('svn pl') in a submenu.
Title: Bounty: CVS plugin
Post by: mandrav on June 23, 2005, 03:21:03 pm
Thomas,

Let me start with many thanks for your hard work. From what you 're saying, I 'm expecting to see the most complete IDE-integrated cvs/svn solution (across all IDEs) :D .

Quote
Another thing: I have not found anything like ProjectIsClean() in c::b. Is there anything like this except walking through all buildtargets? There is cbProject::GetModified(), but that only barks when files have been added or deleted, not when they're modified and saved.

You 're right, there isn't such a function. Let's think about it.
If we had a IsClean() method in cbProject, it could tell us if the project or any of its files were modified. Easy. But knowing if it needs building or not? Hard. The compiler is a plugin and it might not even be available.
What could be done is add a CompilerPlugin::IsBuildUpToDate() method. Combined with cbProject::IsClean() you could get all the info you need.
What do you think?

On another note, you haven't mentioned if you 're planning to open the source to your plugin. If it is so, I think it would be better if it was added in third-party plugins (in CVS). More eyes on it, more testers, more work done and all these in less time.
Your thoughts?

Keep up the good work,
Yiannis.
Title: Bounty: CVS plugin
Post by: rickg22 on June 23, 2005, 05:37:32 pm
Quote from: thomas
This is arguably wrong, but in my opinion, if something is not explicitely caught by an ignore pattern, then it either should be controlled or it should not be in the project directory.


I happen to have files in my project directories which MUST NOT be uploaded to CVS. Like configurations, etc. So adding files by default is a BAD idea. After all, people can choose to add the files manually, don't they?

Just because we can sometimes forget to add a couple of times (Right chief?  :lol: ) doesn't mean it should be done.

But adding files to CVS when adding them to a *project* (not necessarily the directory), I approve, as long as you're asked first. "Do you want to add this file to cvs too?".

My 2 cents :)
Title: Bounty: CVS plugin
Post by: thomas on June 24, 2005, 01:11:25 am
Quote from: mandrav
I 'm expecting to see the most complete IDE-integrated cvs/svn solution (across all IDEs) :D .

Ah, but I haven't even spent a minute thinking about CVS yet. I hope, however, it will be not too bad to implement once SVN is done.
Only other integrated solution I know is in Dev-CPP, and that one does not do much really, does it.
BTW, sourceforge announced that they will soon offer SVN access. Maybe you can be convinced to migrate then, SVN is really an awful lot better  ;)

Quote
CompilerPlugin::IsBuildUpToDate()

Sounds great but might be quite hard work for you to get right (I guess).
What about saving the date/time of a successful build? When build returns no error, keep that date cached (or maybe just the last of these). Whenever a file is modified, it obviously gets a new modification time. One could either compare these, or cache the last time any project file was modified as well. If time_any_file_modified > time_last_successful_build then project is not clean. It is late and i am nearly sleeping, but is that correct? I think so.

Quote
On another note, you haven't mentioned if you 're planning to open the source to your plugin.

I did not think about this at all. It seemed so obvious that a plugin to an open-source IDE must be open source, too. Otherwise, it would be quite absurd...
As soon as the plugin is in a state which I need no longer be ashamed of (i.e. usable without producing an error every few minutes), I will certainly make it open source. I've made a Berlios account the other day to host it (they provide both CVS and SVN), but having it in the main repo will be ok as well, no objections to that.

Quote
I happen to have files in my project directories which MUST NOT be uploaded to CVS. Like configurations, etc. So adding files by default is a BAD idea. After all, people can choose to add the files manually, don't the

Rick, like I said, you do not need to use that feature. If you prefer doing things manually, you can do so. Different people have different needs. You  do not need to click on the checkbox that says "auto" ;)
By the way, svn has a wonderful thing called properties. Among the many things you can do with these, you can define which files, file patterns, and paths are to be ignored (by setting the svn:ignore property). It works pretty much like .cvsignore except that it is 10,000 times cooler.
So if your config files must not be uploaded, then have their pattern ignored, so you can still blindly add everything and you never need to think about it.
Title: Bounty: CVS plugin
Post by: mandrav on June 24, 2005, 08:50:42 am
Quote
BTW, sourceforge announced that they will soon offer SVN access. Maybe you can be convinced to migrate then, SVN is really an awful lot better

Heh, me convinced? I love svn. I started C::B over at tigris.org because they offered svn access, but for low bandwidth reasons I moved it to sourceforge.

Yiannis.
Title: Bounty: CVS plugin
Post by: thomas on June 24, 2005, 11:36:09 am
Quote from: mandrav
Heh, me convinced? I love svn.


Maybe you love this, then:
http://developer.berlios.de/docman/display_doc.php?docid=28&group_id=2

Looks pretty much like sourceforge (they seem to even use the same web interface) but offers svn and a few other nifty things :)
Title: Bounty: CVS plugin
Post by: rickg22 on June 24, 2005, 05:17:32 pm
(Just don't abandon SF! :( )
Title: Bounty: CVS plugin
Post by: thomas on July 06, 2005, 06:02:07 pm
Though I hate publishing badly unfinished stuff, there was no more way around version control (broke it beyond repair once, that's enough). So well, there it is hosted at BerliOS now.

There is a "no-release" binary at the project's page:
http://developer.berlios.de/projects/cb-svn/

Common things like import, checkout, commit, update, add, and delete do work, though, so I thought maybe someone is brave enough to use it already. For those common things, it should work ok.
The binary is a verbatim copy of the one that I used to import the project to BerliOS and to check out my working copy, so I guess at least that functionality can be taken for granted.
Installation should be obvious, but there is some documentation on the site as well, including svn+ssh:// setup.

The souce code should be available via
Code
svn checkout svn://svn.berlios.de/cb-svn/trunk

However, I currently still get the message "svn: Can't open file '/svnroot/repos/cb-svn/format': Permission denied" when trying to check out anonymously (svn+ssh:// does work fine). Probably file permissions must be updated with the next cron job first? I'll look after it again tomorrow.

So long, have fun with it, more to come soon :)
Title: Bounty: CVS plugin
Post by: thomas on July 12, 2005, 08:39:01 pm
Added another "no-release" with a lot more functions today. In particular, property handling works for all properties now (the special ones have custom handlers or run from the menu), most of the preferences are actually respected, a few minor bugs have been fixed, revert works, and there is a minimalist diff viewer.
If you want to check out the sources, make sure to get r9, as r7 had some messing around with file permissions, so a few files were not transmitted properly. r9 checks out fine for me.
Title: Bounty: CVS plugin
Post by: squizzz on July 12, 2005, 11:58:50 pm
Do you plan adding your plugin to official C::B /plugins/contrib CVS repository some day?
I have a strange feeling that your work misses a lot of audience because of not being there. Note that not many users use version control system at all, and even less use SVN (CVS is still more popular solution) - I think having it shipped with C::B sources would both popularize usage of SVN and your plugin much more. Just my 5 cents...

Now installing TortoiseSVN (http://tortoisesvn.tigris.org/) in order to grab your work. :)
Title: Bounty: CVS plugin
Post by: rickg22 on July 13, 2005, 12:21:29 am
I agree with you, squizzz. After all, look at this thread title :P
Title: Bounty: CVS plugin
Post by: thomas on July 13, 2005, 02:03:47 pm
Quote from: squizzz
Do you plan adding your plugin to official C::B /plugins/contrib CVS repository some day?

Hmm... does this work at all? If it does, then I don't know how. It sure is very easy with CVS to set svn:externals on a directory to include another SVN repository in the tree, but I have no idea if CVS has any such thing. Rather, I think it would be necessary to migrate the project to CVS.
But you are of course very right, generally. It sure would be better for its popularity if it was in the CVS tree.
Lets wait until it is in a little more finished. For now, I dread to think about using CVS. If I get the CVS support right, though, maybe CVS could be lived with ;)
 
Quote from: squizzz
Note that not many users use version control system at all

Lol, yes, and CVS contributed a lot to that ;)
When I first thought about using revision control (somewhere around 1995), I was told there was RCS and CVS, the latter being the tool of choice, as it was so much better. So I looked at CVS, and this experience put me off revision control entirely.
At some point in 2002, however, I decided that no matter how painful, I had to start using revision control, as I spent a good quarter of my time messing with a hundred local copies of every file (well you know... you've been there).
Much to my surprise, subversion turned out to be not much of a pain at all. Setting up a functional repo and successfully importing a project took me 30 seconds after reading the docs (as opposed to 2 hours with CVS). And apart from very few occasions, it causes very very little grief (rarely, it gets a file access conflict, and bdb is not backwards compatible, so upgrading to Fedora 4 made my repos unusable - but well, one should use fsfs, anyway).
Thus it became he used subversion, and he lived long and happily ever after.

Quote from: rickg22
After all, look at this thread title

Ah yes, but a man can dream, can't he :)
Maybe Sourceforge finally releases SVN access one day, then no one will be wanting to use CVS any more. At BerliOS (which uses the sourceforge web interface, too), they have it running.
Title: Bounty: CVS plugin
Post by: thomas on July 19, 2005, 07:46:59 pm
Added another snapshot of today's sources as well as a binary release:
http://developer.berlios.de/project/showfiles.php?group_id=4084&release_id=6571

This one has support for TortoiseCVS and should do CVS checkout, update, and commit.

Should do? Well yes... should do. Lacking write access to a CVS server, I have no possibility to confirm that commit actually does anything, but I guess it does :)
The CVS code is quite awkward, but CVS is a really picky with its paramters, too. In particular, it messed around a lot when passed directories as targets. Finally, the code ended up with changing working directory and calling cvs with no target for directories. This is ugly and awkward, but it does not crash and burn...
Checking out code::blocks and freeBSD as "test suite" did work fine, and update seems to work, too. Authentication does work, I believe.
So if you have been waiting for CVS support, then this is the time to try and send feedback.

It seems to me that CVS is unable to do anything without network access. That implies that custom menus according to a file's state cannot be implemented for CVS-controlled projects (you would not want to possibly wait 30 seconds before the menu opens?).
The only way around seems to be parsing CVS/Root and comparing the commit times to file modification times manually.
Should this be a misconception of mine (being a no-CVS user, it is quite possible that I only lack the knowledge about the necessary switch), then I would appreciate being hinted to it :)
Is there anything like "svn status" in CVS?

Ah yes, and most important, the project now has a useless home page with a nice picture, and the dll has a new icon, too.
If you don't get something to work, then at least make it look good ;)
Title: Bounty: CVS plugin
Post by: mandrav on July 19, 2005, 08:35:24 pm
Quote
It seems to me that CVS is unable to do anything without network access.

Correct.
Quote
The only way around seems to be parsing CVS/Root and comparing the commit times to file modification times manually.

Yup, it's the only solution and it's a nightmare, especially around daylight saving times...

Yiannis.
Title: Bounty: CVS plugin
Post by: mandrav on July 19, 2005, 09:05:29 pm
I downloaded the sources and noticed a few things.
First, you 're using the VERSION_1_0 branch of C::B. It's not bad, just something that should be mentioned.
I compiled it using wx2.6.1 and many things (mainly event handlers) were wrong.
I 've corrected all the errors and will upload a patch for you at berlios.
I 've also updated your project file to use the latest and greatest: custom variables. This allows for setting the main paths (wx, codeblocks, etc) in one place (project build options->custom variables) and all project settings are updated :)

Now for the usage:
I tried using your plugin with a project of mine which I have under SVN control (as I do with all my personal projects ;) ). I had 14 files modified to be commited. When I tried to commit them, I got this response:
Quote
svn: Commit failed (details follow):
svn: Can't create tunnel: The system cannot find the file specified.  

Any insight? (I've already setup the plugin's configuration)

Keep up the good work :)

Yiannis.
Title: Bounty: CVS plugin
Post by: mandrav on July 19, 2005, 09:16:53 pm
Quote from: mandrav
I 've corrected all the errors and will upload a patch for you at berlios.

Tough luck. Either berlios doesn't have a patch tracker or you haven't enabled it...
Anyway, here's the patch (http://www.codeblocks.org/tmp/cb-svn-patch.zip).

Yiannis.
Title: Bounty: CVS plugin
Post by: rickg22 on July 19, 2005, 11:06:58 pm
i'm just wondering if it wouldn't be easier to fix the CVS problems between thomas and sourceforge...
Title: Bounty: CVS plugin
Post by: kagerato on July 20, 2005, 04:53:06 am
Quote from: rickg22
i'm just wondering if it wouldn't be easier to fix the CVS problems between thomas and sourceforge...


There are problems?  I thought he just massively prefers SVN.

Anyway, let him develop what he feels is the best solution.  At some point, SVN is very likely to become equally popular as CVS; by then, all the little phantom issues and conflicts between the versioning systems will have dissipated.

As of this moment, I've not heard about any serious bugs or detrimental factors in the SVN implementation.  It seems many people are hailing it as all-around superior to CVS.  The only reasons for not adopting it now seem to be: a.) familiarity with the existing system (and resultingly, a reluctance to learn new methods), and b.) a high degree of prudence and skepticism about new technology (the "let's wait and see" approach).
Title: Bounty: CVS plugin
Post by: mandrav on July 20, 2005, 08:56:41 am
Quote
The only reasons for not adopting it now seem to be: a.) familiarity with the existing system (and resultingly, a reluctance to learn new methods), and b.) a high degree of prudence and skepticism about new technology (the "let's wait and see" approach).

Let me add the more important reason, I think:
The majority of open-source projects are hosted on sf.net and sf does not support svn yet.

Yiannis.
Title: Bounty: CVS plugin
Post by: thomas on July 20, 2005, 10:35:57 am
Quote from: mandrav
I downloaded the sources and noticed a few things.
First, you 're using the VERSION_1_0 branch of C::B. It's not bad, just something that should be mentioned.
I compiled it using wx2.6.1 and many things (mainly event handlers) were wrong.
I 've corrected all the errors and will upload a patch for you at berlios.

Thank you :)
Now lets see if I get through the wxCompile hell alive :)

Quote
Tough luck. Either berlios doesn't have a patch tracker or you haven't enabled it...

The latter. My bad, sorry. Did enable now and uploaded your patch.

Quote from: mandrav
svn: Commit failed (details follow):
svn: Can't create tunnel: The system cannot find the file specified.

Ah, tunnelling is about the only thing that can make you really hate svn. Took me hours to get it running the first time, and the amount of helpful documentation on the internet is near zero.
I do assume that you have a tunnel running to start with, i.e. you can open a functional ssh window to the server (for example using pageant/putty).
The likely reason for this error message is that you used a native file path to your plink executable inside {CommonFiles}\subversion\config, like it is the obvious way to do. Unluckily, the obvious way does not work. You must use all forward slashes like this:
Code
[tunnels]
ssh = $SVN_SSH  C:/tools/plink.exe



Rick:
No problems with Sourceforge :)
Just CVS is giving me the creeps every time I use it. Using SVN proved straighforward from the first minute, and CVS still makes me think "Darn, where is the manual, this is confusing" quite often.
It is also things like this that drive me crazy:
Code
cvs -d :pserver:someone@the.server:/cvsroot/something checkout module -d somedir

There are two "-d" switches in the same command line, they mean entirely different things. And worse, the order of parameters can matter, too. I don't recall an example for that now, but I had a case. Those are things that turn me off. No offense taken if someone uses CVS, but it is just not a thing for everyone.
Another thing that gets me each time is the naming scheme for repositories (I forget to type one of the many colons, mostly the third one, about 50% of the time). Sure enough, CVS existed long before most everybody had heard the word 'URL', so that somehow excuses. But then what is the deal, after one decade, in letting people write "cvs checkout pserver://someone@the.server/cvsroot/something/module -d somedir" instead.
Certainly, TortoiseCVS makes it somewhat less painful, but I still feel uncomfortable with it.
Do not grieve, Sourceforge will soon offer SVN, they announced months ago :)
Title: Bounty: CVS plugin
Post by: mandrav on July 20, 2005, 10:53:22 am
Quote from: thomas
Quote from: mandrav
svn: Commit failed (details follow):
svn: Can't create tunnel: The system cannot find the file specified.

Ah, tunnelling is about the only thing that can make you really hate svn. Took me hours to get it running the first time, and the amount of helpful documentation on the internet is near zero.
I do assume that you have a tunnel running to start with, i.e. you can open a functional ssh window to the server (for example using pageant/putty).
The likely reason for this error message is that you used a native file path to your plink executable inside {CommonFiles}\subversion\config, like it is the obvious way to do. Unluckily, the obvious way does not work. You must use all forward slashes like this:
Code
[tunnels]
ssh = $SVN_SSH  C:/tools/plink.exe

Here's my setup (quite common, I think):
My repositories are on a separate linux server, already setup and working.
In my windows machine, I 've installed TortoiseSVN and that's it. Everything Just Works(tm).

I downloaded and built your plugin. Upon first C::B launch with your plugin, I went to "Settings->Configure plugins->Subversion".
This dialog has two text boxes. The first one was empty (the subversion path). The second contained the path to tortoise's plink.
I looked around a bit and dismissed the dialog (I didn't edit anything). Btw, nice options you got there ;)

Opened a project (under svn control) and right-clicked on the project root. I clicked on "Subversion->Commit (14 files changed)" and I got some assertions.
Note: It would be better to display a friendly error dialog, explaining what to do :)
Anyway, I realized that I had to install subversion for this to work.
Downloaded subversion, installed it and set the path to svn.exe in your plugin's configuration.

I then retried the same procedure as above, to commit the changes of my project.
That's when this error came up:
Code
svn: Commit failed (details follow):
svn: Can't create tunnel: The system cannot find the file specified.


[EDIT]I can't find {CommonFiles}\subversion\config. Where is it hidden? [/EDIT]
[EDIT 2]Found it: It's in %USERPROFILE%/Application Data/Subversion/config[/EDIT 2]

As you can see I haven't touched {CommonFiles}\subversion\config. Should I?
How should I know?
I mean, I use TortoiseSVN and never had to tamper with anything of this sort.
Don't get me wrong. I appreciate all the hard work you 're doing. I just put myself in the average joe's shoes and see if she could make anything out of it.

Conclusion: a little bit more polish and a helpful README with the common pitfalls and you 're set :)

Yiannis.
Title: Bounty: CVS plugin
Post by: thomas on July 20, 2005, 12:27:45 pm
Quote from: mandrav
Here's my setup (quite common, I think):
My repositories are on a separate linux server, already setup and working.
In my windows machine, I 've installed TortoiseSVN and that's it. Everything Just Works(tm).

Yup, pretty normal :) Except you do need svn. Sorry, I thought it came installed with Tortoise.

Quote

This dialog has two text boxes. The first one was empty (the subversion path). The second contained the path to tortoise's plink.

This very much surprises me.
The first one should never be empty. Lacking a better alternative, the plugin tries to find svn.exe with a more or less brute-force search of the most likely locations on the first run (see SubversionPlugin::NastyFind()). If nothing is found, then "svn.exe" is used, assuming that svn is in the path. If svnbinary is ever empty, it is explicitely set to "svn.exe".
The second one, too, surprises me, as it should point to TortoiseProc.exe. The path is obtained from the registry (HKEY_LOCAL_MACHINE\SOFTWARE\TortoiseCVS\RootDir) and TortoiseProc is appended. If that fails, NastyFind() is run on TortoiseProc, too, and if that fails, then Tortoise is assumed not installed. I will have to look over that again, there must be something omitted?

What the program needs is the full pathname to svn like for example C:\subversion\svn.exe (and, if you want to use a Tortoise features like branching or the conflict editor, the full path to TortoiseProc.exe, too)

Quote

I looked around a bit and dismissed the dialog (I didn't edit anything). Btw, nice options you got there ;)

Note a few may still not be functional, but the majority should be.

Quote
How should I know?

By reading the project's documentation ;)
No seriously, getting svn tunnelling to work *IS* evil, and yes, it does not run out of the box.
If possible, you will not want to use svn+ssh://, but https:// instead. I use plain svn:// at home because it needs zero setup and has zero problems. You just enter your username and password in the checkout dialog and you're fine. Your server is in a DMZ anyway, I assume, so why bother.
 Alternatively, for the internet, you can use apache/WebDAV. The advantage is that it has *very* fine grained access control (well, everything that apache does, in fact), and you need no special setup on the client.

But now for wrath, and for glory, and for a red dawn. You do want to use svn+ssh://
What you have to do is this:
1. Understand how svn+ssh:// works. Using this protocol, svn does not authenticate or anything. Instead, it runs via a SSH tunnel as a local user on the server (SSH does everything).
svn pretty much expects a tunnel to be readily available when it calls for it. This means that you have to setup tunnelling so that it works autonomously. It also means that the password fields in the checkout dialog are useless.
2. Have some software installed and running to use SSH. I use putty/plink, but anything should do.
3. I assume you have been using SSH for years anyway, but nevertheless:
- generate a private/public key pair and install your public key on the server
- if you are foolhardy, use a key without password (I do that, *cough*)
- otherwise, put pageant into the autostart folder, so you have to enter your password once after startup (I am too lazy for that, but I tried, it does work).
- make a putty configuration for your server and enter your private key under SSH --> Auth
- now, for as long as pageant is running after entering your password (or always, if you have none), you should be able to double-click on your session, and a SSH window opens without prompting for a password. That works? Great, because that is what svn needs.
- Now, edit %USERPROFILE%/Application Data/Subversion/config. Uncomment [tunnel] and put in the path to plink.exe. Do make sure you use forward slashes. This is a really nasty stumbling block. Save the config file. Open up code::blocks, enjoy.
Title: Bounty: CVS plugin
Post by: mandrav on July 20, 2005, 01:07:22 pm
Quote
The second one, too, surprises me, as it should point to TortoiseProc.exe.

I might remember wrongly about this (I don't have your plugin available here).

Quote
If possible, you will not want to use svn+ssh://, but https:// instead. I use plain svn:// at home because it needs zero setup and has zero problems. You just enter your username and password in the checkout dialog and you're fine. Your server is in a DMZ anyway, I assume, so why bother.

Right, but I use svn+ssh mainly for one-time authentication (using pageant). I enter my passphrase once per session, opposing to once on every commit (or whatever).

Quote
But now for wrath, and for glory, and for a red dawn. You do want to use svn+ssh://

Yes, I do :)

To summarize: I have to setup a tunnel manually before using your plugin.
This surprises me a bit. Couldn't you use plink or something to avoid it?
Hmm...

Thanks for the info,
Yiannis.
Title: Bounty: CVS plugin
Post by: thomas on July 20, 2005, 03:10:36 pm
This is not specific for my plugin. Try running "svn svn+ssh://somewhere checkout" from a cmd prompt. I would be surprised if you could without configuring a tunnel.

Tunnelling for svn is not very well documented anywhere (at least I did not find anything really good), so much of what I am telling you was found out via trial and error. In fact, svn+ssh is the very very worst bit of an otherwise excellent tool in my opinion.
As far as I figured, svn wants to be configured to use plink (or ssh, or whatever) in the [tunnels] section. It then calls plink, telling it what server to connect to, and expects that someone else takes care of the problem.
It then runs svnserve as a local user and takes whatever comes via the tunnel as svnserve's output.
Unluckily, plink will send back "Connect as user:", and svn does not care much about that, so it will hang for a minute and eventually time out. Setting the username and password options does not change a thing.

Funnily, the very same thing will work fine from a Linux command line. The ssh program will prompt you for username and password, and there you go. No tunnel to set up, nothing alike. It just works.

The only working solution I see for Windows is to set up a tunnel with pageant (or a non-encrypted key for the courageous).
Well... ok, another solution would be of course using your own SSH tunnel like Tortoise does.
Tortoise uses a "modified" plink program. No idea what exactly is modified, but I guess they built in an interface so Tortoise can prompt you for a password (for every single connection, unluckily). However, writing a custom plink is a little out of the scope for this plugin, I am afraid ;)

One could also think to run "plink svn" instead. That would run svn as a local process on the server. This sure would work, but it would check out your working copy into your home directory on the server rather than piping them through the SSH tunnel, not quite what we want.
Title: Bounty: CVS plugin
Post by: rickg22 on July 20, 2005, 03:46:17 pm
Quote from: thomas

Rick:
No problems with Sourceforge :)
Just CVS is giving me the creeps every time I use it. Using SVN proved straighforward from the first minute, and CVS still makes me think "Darn, where is the manual, this is confusing" quite often.
It is also things like this that drive me crazy:
Code
cvs -d :pserver:someone@the.server:/cvsroot/something checkout module -d somedir



O.O You mean you're using COMMANDLINE CVS? :shock:
Then what have i been promoting tortoise for? :?

Anyway, maybe this is a mistake of mine - i thought you COULDN'T upload your project to sourceforge via CVS because of config issues, and you and Mandrav couldn't keep your code in sync because of this.

Forgive my ignorance :oops:
Title: Bounty: CVS plugin
Post by: Anonymous on July 20, 2005, 04:06:32 pm
Uhhhhh...... I am stupid. Cannot believe I did not try that before...

I kept wondering how TortoisePlink differs from plink. Well, I found out.

Try this inside the svn config file (with your local file paths, of course):
Code

[tunnels]
### Configure svn protocol tunnel schemes here.  By default, only
### ...
#ssh =  C:/tools/plink.exe
ssh = C:/Programme/TortoiseSVN/bin/TortoisePlink.exe


Now if you run "svn svn+ssh://username@somewhere", then it will use TortoisePlink. And now it is clear what the "modifications" in TortoisePlink are, too - it has a friggin GUI with a password prompt :)

So... no tunnels needed, only need to change one line in svn config, and you get prompted once per commit (or once per session if pageant is running). You can give it a custom name, too, like svn+tortoise:// or whatever you like.
Title: Re: Bounty: CVS plugin
Post by: mandrav on July 31, 2005, 11:59:22 am
Thomas,

I checked out your latest sources and built the svn plugin.
Man, this ROCKS!!!  :lol: 8) :mrgreen:
Worked like a charm :D

To recap:
1) Build and install the plugin
2) TortoiseSVN and Subversion should be already installed
3) Edit %USERPROFILE%/Application Data/Subversion/config:
        Uncomment [tunnel]
        Add under [tunnel]: ssh = C:/Program Files/TortoiseSVN/bin/TortoisePlink.exe
4) Launch C::B and right-click an open project :D

Although I haven't tested it excessively, just normal usage, I haven't found any problems (crashes) with it. Do you think it could be included in the RC1 update that 'll be released soon?
Also, do you mind explaining the svn-properties thing? It seems very interesting but I know nil about it  :oops:
A link would be fine :lol:

Yiannis.
Title: Re: Bounty: CVS plugin
Post by: Urxae on July 31, 2005, 12:35:10 pm
Also, do you mind explaining the svn-properties thing? It seems very interesting but I know nil about it  :oops:
A link would be fine :lol:
I found this (http://svnbook.red-bean.com/en/1.1/ch07s02.html) to be a very good explanation. I've never used them myself, but it looks like you can do some nifty stuff with it.
Title: Re: Bounty: CVS plugin
Post by: mandrav on July 31, 2005, 01:34:19 pm
Thanks for the link Urxae :)

Yiannis.
Title: Re: Bounty: CVS plugin
Post by: thomas on August 01, 2005, 03:30:57 pm
Ah sorry, was away for the weekend. The svnbook pointed to by Urxae is a great reference. If there is anything to know about svn, its in there :)
Only thing I found that is not in there is the lock command, but that one is quite new, most servers don't support it yet, and locking is evil, anyway.

Properties in 3 sentences:
1. any kind of data (copyright message, a text explaining what a file is good for, an image thumbnail, anything) you wish to attach to one or more files or directories
2. special metadata which controls per-file keyword substitution (CVS can only do that globally, or not at all), executable flag, line end convention, mime-type, or ignore list
3. all of this data is revision controlled, which is pretty darn cool

The plugin tries to make property handling as little pain as possible. Binary-type or set-type properties are displayed inside the menu (with checkmark if active) and can be toggled by one click.
To promote the use of general keywords (like copyright info), the import dialog allows to set some properties right away.

Please do note that some of the automatic gimmicks (like the above prop-setting in the Import dialog, or auto-reload after checkout) do not all work. The way of program invokation and return value passing has been changed substantially since the last release. This requires a lot of previously working code to be rewritten yet.
The good side is, however, that overall behaviour is a lot friendlier now (non-blocking).
Title: Re: SVN plugin
Post by: thomas on August 05, 2005, 06:45:56 pm
Released 0.4.1 (both source and binary) today:
http://developer.berlios.de/projects/cb-svn

This release is an awful lot better than the ones before. A few things have been reimplemented, moved, or renamed and the overall behaviour has been substantially improved since the 0.3 releases (work on while a transaction is running).

The plugin will now allow diff/merge either via Tortoise, KDiff3, WinMerge, or tkdiff. The good news is KDiff3 and tkdiff are available almost everywhere. Detection is automatic.

Also, the 0.4 release can generate patch files from the project manager menu.
The resolved command is now supported, too.
Subversion 1.2 locking is supported (if your server and your client support it!).
Title: Re: SVN plugin
Post by: RJP Computing on October 16, 2005, 11:58:17 pm
Has there been any developement on this?

I tried the one from the website and it doesn't seem to work. Every time I try to add a project to a repository it closes C::B without any message at all. If I try to go to the "Configure Plugins" it crashes C::B. I use Subversion a lot and this is going to be a great plugin. Please let me know if there is anything I can dso to help.
Title: Re: SVN plugin
Post by: thomas on October 17, 2005, 01:28:59 am
Svn support actually works quite reliably, I work with it all day, cvs support is (still) a bit awkward, that's going to be fixed soon though.
There is a bug in the version that is released on the BerliOS site which indeed causes a crash if you do not have svn properly installed, or if the plugin cannot find it - that bug has been fixed in the repository. The version coming with RC2 will not have that bug any more, and as soon as  I can be bothered to clean up a few things, a better version will be released on the Berlios site, too. Few days patience please, have a busy week.
Title: Re: SVN plugin
Post by: RJP Computing on October 17, 2005, 10:27:48 pm
If I try to go to the "Configure Plugins" it crashes C::B.
Well I found a solution to this was to place the svn.zip file in the '<CodeBlocks Install>\share\CodeBlocks' directory.

I also noticed if I opened a project that was currently under svn and did an update to the "HEAD" revision it deleted the file and then nothing. I don't know if this matters, but I am doing this on a flash drive. Sometimes things like that matter. I am going to try from a local disc later and I will get back to you.

Can you make it so that the svn.exe can be in the CodeBlocks install directory. I would like to make a custom installer and just include the needed files. It would be a great help.
 
I am excited to see the new version. :lol:

Thanks!
Title: Re: SVN plugin
Post by: thomas on October 18, 2005, 11:09:03 am
Well I found a solution to this was to place the svn.zip file in the '<CodeBlocks Install>\share\CodeBlocks' directory.
Ah, that of course would be the case. Not that this is an excuse, but that is the case with any plugin coming with Code::Blocks (the compiler and debugger are smart enough to disable the compiler menu, but you can still fool the compiler by using the project manager). Added a check when the plugin is loaded.

I also noticed if I opened a project that was currently under svn and did an update to the "HEAD" revision it deleted the file and then nothing.
There is no reason for that which is obvious to me. The plugin does not touch your project files, neither does it ever delete one.
If you select "Update to HEAD", then it will change directory to the working copy, set a few necessary environment variables (SVN_SSH, for example), and invoke svn update -r head.

Can you make it so that the svn.exe can be in the CodeBlocks install directory. I would like to make a custom installer and just include the needed files. It would be a great help.
In the upcoming release, the value of HKEY_CURRENT_USER\Software\Code::Blocks\Code::Blocks v1.0\app_path is one of the search paths for the svn and cvs executables under Windows. Under Linux, executables are searched in /usr/bin, /usr/local/bin, /opt/bin, and /bin.
If all fails, the plugin simply uses the tool's name and relies on the PATH variable on both platforms. So if svn is in your PATH, then it should always work.
Title: Re: SVN plugin
Post by: Urxae on October 18, 2005, 03:07:53 pm
I also noticed if I opened a project that was currently under svn and did an update to the "HEAD" revision it deleted the file and then nothing.
There is no reason for that which is obvious to me. The plugin does not touch your project files, neither does it ever delete one.
If you select "Update to HEAD", then it will change directory to the working copy, set a few necessary environment variables (SVN_SSH, for example), and invoke svn update -r head.

Well, the obvious reason that might happen would be that the file in question was deleted in the repository, so svn update removed it.
Title: Re: SVN plugin
Post by: thomas on October 18, 2005, 03:23:04 pm
Well yes, but you'd think one remembers having done a svn delete, and it would show a big "D" in the output log, too ;)
Title: Re: SVN plugin
Post by: Urxae on October 18, 2005, 08:50:01 pm
Well yes, but you'd think one remembers having done a svn delete, and it would show a big "D" in the output log, too ;)

One wouldn't necessarily remember a svn delete performed by someone else with write access to the repository. About the big "D" I wouldn't know (I currently use TortoiseSVN, not your plugin).
Title: Re: SVN plugin
Post by: kisoft on October 20, 2005, 03:55:33 pm
Released 0.4.1 (both source and binary) today:
http://developer.berlios.de/projects/cb-svn
...

Great work!

This version have some troubles with C::B plugin manager.
I patch 2 files:

File: svn.h
Code
#ifdef __cplusplus
extern "C"
  {
#endif
    PLUGIN_EXPORT cbPlugin* GetPlugin();
#ifdef __cplusplus

  };
#endif
was changed on:
Code
CB_DECLARE_PLUGIN();

File: svn.cpp
Code
cbPlugin* GetPlugin()
{
  return new SubversionPlugin;
}
was changed on:
Code
CB_IMPLEMENT_PLUGIN(SubversionPlugin);

Cool, it's work!  :D

C::B: CVS [20.10.2005], wx2.6.2, Win2000, TortoiseCVN

PS Testing to be continued..

Title: Re: SVN plugin
Post by: thomas on October 20, 2005, 04:32:35 pm
Ah, this is new as of October 7, was not aware that there are now two CUMs for that, thanks for pointing out.
Will modify the source accordingly. :)
Title: Re: SVN plugin
Post by: RJP Computing on November 01, 2005, 02:27:57 pm
Thomas,

Can you release your fixed version. It is dificult for me to build it because I am not setup to develope plugins. Thanks it is working great as long as you have both CVS and SVN installed.

Thanks.
Title: Re: SVN plugin
Post by: thomas on November 01, 2005, 02:38:36 pm
I have no other binary than the one that comes with RC2 myself at this time either, sorry.

Presently, I am splitting off CVS into a separate module for the 0.5 branch, so the code in each separate module will be cleaner and easier to manage (it is a pain to deal with a dozen special cases everywhere). The 0.5 branch does not compile yet, though. When the branch compiles without errors and does not immediately crash, I will merge it to the trunk and release that version. :)
Title: Re: SVN plugin
Post by: RJP Computing on November 02, 2005, 02:25:06 pm
Ok sounds ok. What is the ETA on that. I am tring to get a group project going and I need good svn integration.

Thanks for all your hard work.
Title: Re: SVN plugin
Post by: thomas on November 03, 2005, 04:50:10 pm
Hopefully not longer than a week or so.
Title: Re: SVN plugin
Post by: RJP Computing on November 21, 2005, 05:16:35 pm
Hi Thomas,

I updated to the latest cvs of C::B and now the latest svn plugin stopped working. Can you duplicate the same thing? Has there been any progress in the next release of the cb-svn plugin? Thanks. I really use this plugin a lot.
Title: Re: SVN plugin
Post by: Urxae on November 21, 2005, 05:45:36 pm
Hi Thomas,

I updated to the latest cvs of C::B and now the latest svn plugin stopped working. Can you duplicate the same thing? Has there been any progress in the next release of the cb-svn plugin? Thanks. I really use this plugin a lot.

I'm not Thomas, but I do have the plugin working on my CVS codeblocks (+ some local modifications).
Attached is a patch for the current trunk that makes it work for meTM. Don't forget to edit the batch files to reflect your Code::Blocks CVS path.

[attachment deleted by admin]
Title: Re: SVN plugin
Post by: thomas on November 21, 2005, 08:57:57 pm
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 ;)
Title: Re: SVN plugin
Post by: Urxae on November 21, 2005, 09:13:59 pm
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).
Title: Re: SVN plugin
Post by: MortenMacFly on November 26, 2005, 07:40:40 pm
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.
Title: Re: SVN plugin
Post by: mandrav on November 26, 2005, 08:12:38 pm
Thomas will be back after November 30th, so you 'll have to wait a bit for an authoritative answer ;)
Title: Re: SVN plugin
Post by: Urxae on November 27, 2005, 01:17:02 pm
Hmm, it seems my patch no longer works with the latest SVN version of C::B... :(
Looks like a nullpointer-dereference on startup. :?
Title: Re: SVN plugin
Post by: MortenMacFly on November 27, 2005, 01:23:21 pm
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.
Title: Re: SVN plugin
Post by: mandrav on November 27, 2005, 01:24:43 pm
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...
Title: Re: SVN plugin
Post by: thomas on December 01, 2005, 11:45:15 am
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:

Quote
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.
Title: Re: SVN plugin
Post by: MortenMacFly on December 01, 2005, 02:59:13 pm
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.
Title: Re: SVN plugin
Post by: RJP Computing on December 02, 2005, 08:31:10 pm
I am tring to compile the patch but I can't get it. Can somebody please post the compiled patched version.
Title: Re: SVN plugin
Post by: Urxae on December 02, 2005, 08:38:42 pm
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 :(.
Title: Re: SVN plugin
Post by: RJP Computing on December 04, 2005, 09:29:01 pm
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.
Title: Re: SVN plugin
Post by: Urxae on December 05, 2005, 12:16:40 am
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 (http://home.wxs.nl/~fvbommel/cb-svn-binary-urxae.zip).
Title: Re: SVN plugin
Post by: RJP Computing on December 05, 2005, 02:48:08 am
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 (http://home.wxs.nl/~fvbommel/cb-svn-binary-urxae.zip).

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?
Title: Re: SVN plugin
Post by: Urxae on December 05, 2005, 03:07:00 am
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.
Title: Re: SVN plugin
Post by: RJP Computing on December 05, 2005, 05:09:01 pm
Yup I am using there build of C::B. Thanks for trying.

Is there any way to explain, posibly a tutorial, about what needs to be compiled and what source is need to help the developement of this plugin along? I have the source for the SVN plugin and the SDK from the C::B website but I get all kinds of errors when compiling the plugin. I think the version of the SDK for C::B is old and that might be the problem. How do I update the SDK so I can work with plugins using the builds that are beyond the current RC?

I know I have half the information. Just enough to be a pain. But I would love to help out once I get up to speed.
Title: Re: SVN plugin
Post by: Urxae on December 05, 2005, 05:44:45 pm
Basically, the SDK must match the C::B binaries. It'd probably be best if you could get Ceniza and/or Therion to also provide the SDK corresponding to their binaries (as a separate download).
Title: Re: SVN plugin
Post by: takeshimiya on December 05, 2005, 06:05:49 pm
No, it would be better if the SVN plugin would be in the SVN repository don't you think? lol :lol:

Is there any reason of why it's not on contrib plugins?
Title: Re: SVN plugin
Post by: thomas on December 05, 2005, 06:07:13 pm
The easiest way to update the SDK is to copy over the headers from the Code::Blocks sources. Note that you need compatible link libraries for wxmsw26.dll and codeblocks.dll, too (matching the exact build that the plugin is to be used with). If you have compiled Code::Blocks yourself, just copy those files too (or set the linker's path). If you still use RC2, then you can download the matching SDK from codeblocks.org. If you use an unofficial build, then... I don't know -- if the build includes the libs, then all is fine, if it does not, then you have a problem.

However, working on the plugin now may not make an awful lot of sense, because your precious work will be worthless after the next release (which is finally being worked on).

I had stopped working on the plugin about 3 weeks before RC2 came out and (despite having planned otherwise) only taken up work again on Saturday.
In the mean time, a lot of significant things in Code::Blocks have changed, and cvs is no longer on the feature list, so an almost complete rewrite reusing some of the existing components seems easier than working on with the existing sources.
Apart from that, significant changes to UI, behaviour, and settings are being made (which are neither compatible with the old versions, nor with Urxae's modifications).
Title: Re: SVN plugin
Post by: thomas on December 05, 2005, 06:08:22 pm
Is there any reason of why it's not on contrib plugins?

There is a reason: it is rubbish.

As soon as the next release compiles, it will be included via svn:external.
Title: Re: SVN plugin
Post by: killerbot on December 05, 2005, 07:06:08 pm
I would not throw away the cvs stuff. CB talking for other projects with cvs servers reamains an inrteresting functionality.
Just like I created a plug-in for ClearCase.
Title: Re: SVN plugin
Post by: thomas on December 06, 2005, 12:24:56 am
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?
I just found out why - by mere coincidence (reinstalled TortoiseSVN).
TortoiseSVN really does no longer come with a svn executable! Obviously, the plugin cannot find it, if it is not there.
So for the future, users will have to install subversion, and optionally TortoiseSVN, the latter alone is not enough.

I would not throw away the cvs stuff. CB talking for other projects with cvs servers reamains an inrteresting functionality.
Just like I created a plug-in for ClearCase.
That's not what I said. The primary objective is to get svn to work. Incorporating CVS at the same time makes the code complicated and unmanageable, and stalls the development of the primary objective. Therefore, cvs is taken out of that module.
Title: Re: SVN plugin
Post by: killerbot on December 06, 2005, 07:45:27 am
I totally agree, keep things clean and simple :

- plug-in for svn
- plug-in for cvs
- plug-in clearcase
- plug-in for perforce (I'm gonna start working on it)


Lieven
Title: Re: SVN plugin
Post by: cborders on January 09, 2006, 11:03:03 pm
I saw the issue regarding this plugin on the download page so I installed svn, but now I can't seem to find a link to download the plugin, where can I get it?
Title: Re: SVN plugin
Post by: MortenMacFly on January 09, 2006, 11:10:58 pm
[...] where can I get it?
Via SVN from: http://developer.berlios.de/projects/cb-svn/ (http://developer.berlios.de/projects/cb-svn/). Look through the forum for a compatibility patch to run this version with the current SVN-HEAD of Code::Blocks.
Morten.
Title: Re: SVN plugin
Post by: takeshimiya on January 10, 2006, 12:47:04 am
Mental note for when the SVN plugin get's back to life: Make it work with both SVN and TortoiseSVN.
As TortoiseSVN doesn't come anymore with svn.exe, but still it let's you do almost all (all?) by the command line.
It will be a pain to tell users that they need to download another 5mb more for making the C::B SVN plugin work.
Title: Re: SVN plugin
Post by: thomas on January 10, 2006, 12:50:27 am
They will have to, though, because the plugin will not work with TortoiseSVN.
What it will do in respect to TortoiseSVN is, it will offer some additional functionality. The standard functionality runs through svn.
Title: Re: SVN plugin
Post by: jsiebert on June 14, 2006, 01:21:05 pm
Hi there,

are there any news on the svn plugin? Is it currently worked on?

Greetings

Jens
Title: Re: SVN plugin
Post by: sethjackson on June 14, 2006, 02:02:22 pm
Hi there,

are there any news on the svn plugin? Is it currently worked on?

Greetings

Jens

Hi. This will probably answer some of your questions. :)

http://forums.codeblocks.org/index.php?topic=3122.0

(Specifically thomas's first post)
Title: Re: SVN plugin
Post by: jsiebert on June 14, 2006, 02:45:24 pm
Hi,

thanks for the info! Next time I put on my glasses before searching the forum ;-)

Greetings

Jens
Title: Re: SVN plugin
Post by: sethjackson on June 14, 2006, 02:56:23 pm
Hi,

thanks for the info! Next time I put on my glasses before searching the forum ;-)

Greetings

Jens

Sure no problem. :D
Title: Re: SVN plugin
Post by: frankmail007 on July 20, 2006, 08:38:40 am
Is this plugin ready for using? If so, where to download it?
Title: Re: SVN plugin
Post by: sethjackson on July 20, 2006, 02:34:28 pm
Is this plugin ready for using? If so, where to download it?


Nope it isn't ready yet......

http://forums.codeblocks.org/index.php?topic=643.msg11076#msg11076
http://forums.codeblocks.org/index.php?topic=3122.0
Title: Re: SVN plugin
Post by: Alca Isilon on August 18, 2006, 04:03:20 pm
Are the sources for this plugin anywhere available (e.g. in the SVN repository)?

I'd like to give a look at it and help with its development.