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

Team System aka Team Block idea

<< < (4/7) > >>

eranif:
Hi,


--- Quote ---If that's so, a very good (and comfortable) solution would be to make a server-client (C++) C::B bugtracking plugin with an sqlite/mysql backend, and another implementation of the client in PHP, so that the bugtracking data can be viewed from both inside C::B local/remotely and from the web.

--- End quote ---

Again, I want to recommend a very nice tool I was working with, both in php & mysql - phpbugtracker
http://sourceforge.net/projects/phpbt

Eran

MariuszP:
Thanks for giving me back my thread :D
Takeshi: Actually I was thinking about something like that. I Was even thinking about doing db access using php web services. Don't know if this would be good idea but surely it would be portable.
As for trac - I've heard a little bit about that. Don't know if I will follow that pattern or maybe create simpler system. As for one thing I'm quite sure - there is a need to create some links between bugs and their orgin, their resolution in connection to svn versions. I'mean - it would be good to attach information about: in which svn version this bug appeared for the first time, and in which it was resolved.

I plan to create simple solution during first few iterations, and then build up another features. Also - first few iterations will work with local server instead of remote as this is much easier to handle.

takeshimiya:

--- Quote from: eranif on August 28, 2006, 01:20:50 pm ---Again, I want to recommend a very nice tool I was working with, both in php & mysql - phpbugtracker
http://sourceforge.net/projects/phpbt

--- End quote ---
Yes, I know it, and using it could serve as a start because it's made in PHP, but mind that it lacks the svn, wiki and roadmap integration.


--- Quote from: MariuszP on August 28, 2006, 03:36:56 pm ---As for trac - I've heard a little bit about that. Don't know if I will follow that pattern or maybe create simpler system.

--- End quote ---
Make sure to check it deeply, it haves the best integration I have found.


--- Quote from: MariuszP on August 28, 2006, 03:36:56 pm ---As for one thing I'm quite sure - there is a need to create some links between bugs and their orgin, their resolution in connection to svn versions. I'mean - it would be good to attach information about: in which svn version this bug appeared for the first time, and in which it was resolved.

--- End quote ---
Yes, trac just does that, and even shows automatically the code changes for a bug/revision.
The latest versions of TortoiseSVN now includes a Bug-ID string, so you'll want to use it.
See here: http://tortoisesvn.tigris.org/issuetrackers.html

Game_Ender:
I don't know if having the bug tracking application integrated into the IDE will give you that much of a benifite.  I use Xcode and SVN + Trac at work.  I have a browser almost open for viewing documentation and such.

What do you hope to achieve by reinventing trac and then recreating the interface within Code::Blocks?  If you really wanted that kind of information in the IDE, you could make a pluggin for trac that allows remote use, and then a C++ client for Code::Blocks and save yourself lots of time.

If my questions seem off base could you layout a clear set of features for what Team Blocks will contain?

takeshimiya:

--- Quote from: Game_Ender on August 29, 2006, 01:13:51 am ---What do you hope to achieve by reinventing trac and then recreating the interface within Code::Blocks? 

--- End quote ---
Speed and usability of course, it would be far more comfortable doing Right-click->Add issue inside C::B, navigating the current issues without leaving the IDE (thus with zero possible distraction), integrating TODO lists from C::B with it, and you can think a lot more possibilities.
The "I" in IDE is for Integrated, so sure you can use external documentation/bugtracking/compilers/whatever, but it's more comfortable to have everything in one place.


--- Quote from: Game_Ender on August 29, 2006, 01:13:51 am ---If you really wanted that kind of information in the IDE, you could make a plugin for trac that allows remote use, and then a C++ client for Code::Blocks and save yourself lots of time.

--- End quote ---
Well, that's a very good option too and it will save lots of time reinventing the wheel. :)
However it faces a little problem: trac itself and it's python dependency.
To put it simply, PHP is far more extendend in hostings than Python, aside that trac is not easy to install.

Having a SQlite backend (without more dependencies) as a C++ C::B plugin would mean that it will not requiere having to install any server software (be it apache/mysql/whatever) to use it in a local way (common usage for a 1-person development).
And having the DB in SQlite would mean that it will be easily accessed from PHP from a web interface (common usage for a team development).


But in a way, I think the best-fit-all solution would be to use the current Trac SQlite DB schema (and make compatible with it).
That will save from initially having to write the Web code, thus reusing Trac, and if it later proves to be worth, write a PHP version.
Put it simply, the C::B version will not have any Trac dependency, but it will be DB-compatible.

Navigation

[0] Message Index

[#] Next page

[*] Previous page