Version control lack is a complete showstopper for C::B

[nelson777]

Hello,

How's version control feature for C::B ? I love C::B, but can't use it because I need version control (Git preferably).
I step out to Eclipse a while ago due to this but I'm always taking a look to see when C::B implements it.

So, when will we see C::B get professional ? About time C::B community understand that version control is a basic need and not a "nice feature to have". And it has to be solid, allow code comparation with older versions, and give other info like Eclipse does it. This should be the main priority for the team, not some "wanted feature for a future version". Not having it is a complete showstopper that block lots of people from using C::B, including me.

So if I like Eclipse, why don't I stick to it and forget C::B ? Because Eclipse is too heavy, because Eclipse lacks a code ordering more c++ like, as C::B has, because C::B has a more familiar feeling, because gdb support is better and simply because I like most the C::B way of doing things. But I really need version control.

By the way, few users would care to came here and tell this to you. Most people, look, see that it doens't fit their requirements and simply go away. If I'm saying this is because I really like C::B and want to get back to it.

-Nelson

[MortenMacFly]

How's version control feature for C::B ?

There are plenty of version control plugins for C::B around. You can also use Tools+ plugin to get started.

I personally prefer external version control software because if you do version control seriously then there is way more then just commit/update and stuff. And personally I believe it makes not sense to copy what is already available into Code::Blocks.

If you are willing to pick up one of the version control plugins to continue development on it so it fits your needs - feel free to do so.

[nelson777]

"There are plenty of version control plugins for C::B around. You can also use Tools+ plugin to get started." - Morten

Well, they really should be around, 'cause I can't fine none. None listed in the wiki, none in C::B page, none in the forums, can't find them in Google... where are them ? will I have to hire a invisible web expert to find them ?

And then you tell me to use Tools+ and when I look for it, I find that Tools+ plugin allows for menu items configurations...  Jesus...

Morten, I'm a free software supporter for some time and I know that when we use free software, we should help instead of criticise and I really would like to have the time to support this project with what it lacks most and that blocks it from reaching the "de facto" standard for C++ IDEs (and it can get there).
Unfortunately I ain't got the time to do this.
What I have time to do is to tell you that we can perfectly live with small bugs from the IDE. What we really can't live without is decent version control support. And by "decent" I mean a version control that just doesn't open terminal windows. It should be integrated with the IDE, with file version comparasion, history etc, like Eclipse does it. What I have time to tell you is that what your team should focus is version control more than anything else. Take the example of Gimp project that has refused to develop single window interface for a long time with a great number of potential users asking for it, only to see lots of people that really wanted to use free software, be forced to go back to Photoshop and in the end they were forced to do it or watch the project sink.
You tell me we shouldn't copy things that C::B already has, but I don't see it having. And if we are speaking of copying things, why are the developers team insisting in developing a visual dialog builder, that is cumbersome and only allows the development to a certain point, after which, we have to alter code by hand because there are many features and customizations we need to use and it doesn't support, if we already have wxFormBuilder that does the same job ? Version control is by far more important that visual design of the dialogs.
I wish you can see me not as a lazy ass that comes here just to criticize and does nothing but someone that even not being able to help right now, wants to see a very good free software project reach the standard it deserves.
What I think you will tell me next, is that it's only me that want this feature so badly. Well maybe I'm wrong. Maybe this is not a feature that many people want. So why don't we make at least a poll of what features are more desired to the community to guide the developer team of what is more important to enhance C::B ? My view is that version control will win by knock out.

-Nelson

[oBFusCATed]

Unfortunately I ain't got the time to do this.

We are in the same position and we have another stopper - we don't feel it is worth it.

...if we already have wxFormBuilder that does the same job ? Version control is by far more important that visual design of the dialogs.

There was a developer that felt it is useful feature and had the time to implement it, simple as that.
This is how open/free software works, someone who has time and desire to implement something and does it.

You have too few options:
1. implement it yourself and then you should prepare to maintain it
2. pay someone else to implement it
3. wait for someone to feel it should be implemented

You don't need the tool+ plugin. The current integration works in the tools menu, too.
But you're right we don't have documentation and it is not that easy to come to the setup.
I'll try to write something in the next few days.

[MortenMacFly]

Search for "SVNInside", "cbvcs", "cb_svn" "CBTortoiseSVN" and there was also something for Sourcesafe.

I agree that version control is important - I use it everyday in all of my projects. But I am also telling you: You cannot beat what's there already, especially not in an OpenSource project. In the end - what version control system should we support? There are many - CVS, SVN, GIT, HG, Perforce, SourceSafe an so on... what shall we support? All of them? No way. Which to start with? You tell "A" others say "B". I for myself work with CVS, SVN, GIT and HG, so I would like to see all of the supported.

I for myself can live very well with source control not coupled with the IDE, but as an external tool. Because it has many advantages, one of it is that you don't need to follow the rapid development of the source control systems itself. This is far more robust and feature-rich than anything we can implement or which is already there. Sure I would like to see an integration, too - but at what cost?

If you are willing to pick up one of the above plugins, make it fit to your needs and provide us with patches I am happy to assist and maybe even integrate it into C::B's main source tree. But so far, all of these plugins lacked functionality or were not stable enough, or the development has stalled suddenly. What would you tell to people claiming they are missing version control integration if you were in our position?

[jarod42]

Some VCS do need integration to be workable.
For example, with Perforce, files are in read-only mode until we "edit" them
(so tools which edit the file must tell to Perforce to edit the file :-/ )
but as soon we don't need a "auto-lock"/auto-edit feature, I prefer to use dedicated VCS tool.

"Correct" VCS doesn't need integration.

[nelson777]

"In the end - what version control system should we support? There are many - CVS, SVN, GIT, HG, Perforce, SourceSafe an so on... what shall we support? All of them? No way." - Morten
"What would you tell to people claiming they are missing version control integration if you were in our position? " - Morten

Morten... I understand your position. Really. But it's kinda like I understand hunger in today's world. There are reasons for it, maybe even good reasons. There are very understandable factors that lead to that. But people continue to die and it's absolutely unnaceptable no matter what.
As for C::B I was reading what you wrote, understanding, tried to see by your eyes, but as I was doing that I have my Eclipse CDT open with my project in it (you now, the one I started in C::B and imported to Eclipse because I need good version control support), with perfect version control integration for ALL major version control systems, file comparation, history (local and remote), author identification for code modifications, code refactoring, automatic make file creation, a fully customizable interface, many different code views and code filters, better code editing facilities and for the final kill the exceptional Mylyn plug-in that allows me to mantain an history of code modifications for a certain task.... case closed. And I'm sure you know I only mentioned some of the features.
I will end this post and get back to it. For now Eclipse CDT is absolutely the IDE king... and as the americans say... it's hard to beat the king.
Finally, I really wish you guys can make C::B a better IDE, but it really has to rise up to the challenges it faces.

-Nelson

[MortenMacFly]

For now Eclipse CDT is absolutely the IDE king... and as the americans say... it's hard to beat the king.

You luckily have the freedom to chose, don't you? Before I came to C::B I was using Eclipse and I still have to use it for some projects. Everybody has its own priorities and needs. Yours are different so C::B is not for you. That's fine.

However, if people are not willing to take part in a community developing alternatives they have to stick to whatever the are used to use. You cannot really compare Eclipse to C::B in terms of development team and time used to develop. In Eclipse, you have WAY more developers, a strong financial background and a long-term history. If you were really looking for alternatives to that and are not happy with C::B I don't wonder. And to make sure you don't waste our time again: C::B will never reach the level of functionality like Eclipse in many areas, but it has enough other strong benefits that make it my favourite IDE over Eclipse (and I am only talking for myself).

Bye!