ZeosLib Still in Development?
Moderators: gto, cipto_kh, EgonHugeist
-
- Fresh Boarder
- Posts: 18
- Joined: 27.04.2011, 21:01
- Location: Brazil
- Contact:
ZeosLib Still in Development?
I have search in many places, but i dont found any notice about this, the zeoslib still in developing? i make this question because i chance all libs in my projects, now i using firebird 1.5 with dbxpress, but i want to chance to firebird 2.1 with zeos, and in the future to 2.5. i can help in something in developement?
-
- Fresh Boarder
- Posts: 18
- Joined: 27.04.2011, 21:01
- Location: Brazil
- Contact:
It's good my friend, i decide chance for the zeoslib, because the dbxpress are a close plataform, and i don't want to change my IDE every new version of dbexpress.seawolf wrote:As stated some days ago, we are in the process of restart the development.
Anyway it look to me FB 2.1 works well .. I try do some tests with FB 2.5 in order to verify all works as usual
May i can help in this process of restart de development, if i can just tell me how, and the process and we can give new breath to this awesome project.
Thanks.
- mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
Hi,
After a very long time I'm finding some more time again to process this forum. So finally I come to answering your calls.
As seawolf said, we're hoping we can restart the development a little. As lack of control over the subversion server seemed to be one of the bottlenecks we recently decided to use the sourceforge subversion hosting instead of the firmos.at one. The main decision factor was that I can delegate all administration rights with one action in case I decide to retire and another volunteer turns up. The sourceforge administration tools also make it easy to allow svn access for users we don't really know yet. With the previous repository we had to ask for manual interventions each time a new account had to be created or a dead account had to be removed.
What's needed now to get involved?
- SVN client software
- a sourceforge account I can grant rights to
- a zeoslib test suite environment you can use before committing your patch to verfy you didn't break any existing functionallity (at least for your preferred compiler and the database your patch is targeted to.
- a first patch (against tsting branch).
- some search work to find my private email address.
After a very long time I'm finding some more time again to process this forum. So finally I come to answering your calls.
As seawolf said, we're hoping we can restart the development a little. As lack of control over the subversion server seemed to be one of the bottlenecks we recently decided to use the sourceforge subversion hosting instead of the firmos.at one. The main decision factor was that I can delegate all administration rights with one action in case I decide to retire and another volunteer turns up. The sourceforge administration tools also make it easy to allow svn access for users we don't really know yet. With the previous repository we had to ask for manual interventions each time a new account had to be created or a dead account had to be removed.
What's needed now to get involved?
- SVN client software
- a sourceforge account I can grant rights to
- a zeoslib test suite environment you can use before committing your patch to verfy you didn't break any existing functionallity (at least for your preferred compiler and the database your patch is targeted to.
- a first patch (against tsting branch).
- some search work to find my private email address.
-
- Expert Boarder
- Posts: 164
- Joined: 18.03.2008, 13:03
- Contact:
Hello, mdaems,
i wanted to ask if You had considered changing SVN to Git? SourceForge supports that SCM system too. It would be a good time to make that transition if You think of moving the repository.
There's some info on distributed SCM systems:
http://www.infoq.com/articles/dvcs-guide
i wanted to ask if You had considered changing SVN to Git? SourceForge supports that SCM system too. It would be a good time to make that transition if You think of moving the repository.
There's some info on distributed SCM systems:
http://www.infoq.com/articles/dvcs-guide
- mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
Wild_Pointer,
Ouch... This was a question I was waiting for, but didn't know how to answer yet.
So I did some reading after work today. And guess what? Seems like your info points indirectly to some sources which say 'As long as your project team is smal enough you don't need DVCS' and 'This article is a bit outdated because SVN has become much smarter during last years' (and the article is already three years old).
And I can confirm, the merge tracking in svn is quite good nowadays (using a 1.7 client), so the most important advantage is more or less gone.
I did experiment with bzr some time ago. And actually, I didn't really like the 'distributed' thing.
The repository move happened a month ago already and was dead easy: create repos, svnsync init, sync, start using the new repository.
So, up to this moment I see no reason to switch to git at all. It would only give me a new environment to get used to.
But these articles also told me there should be no problem for users using git to keep a local repository which updates from and pushes to our central svn system.
Conclusion : I'm not against switching to a DVCS, but I see no advantages with the current size of the active development team. The moment we have more active commiters that actually start getting trouble with bubvrsion, I'll be happy to reconsider this 'decision'.
Mark
Ouch... This was a question I was waiting for, but didn't know how to answer yet.
So I did some reading after work today. And guess what? Seems like your info points indirectly to some sources which say 'As long as your project team is smal enough you don't need DVCS' and 'This article is a bit outdated because SVN has become much smarter during last years' (and the article is already three years old).
And I can confirm, the merge tracking in svn is quite good nowadays (using a 1.7 client), so the most important advantage is more or less gone.
I did experiment with bzr some time ago. And actually, I didn't really like the 'distributed' thing.
The repository move happened a month ago already and was dead easy: create repos, svnsync init, sync, start using the new repository.
So, up to this moment I see no reason to switch to git at all. It would only give me a new environment to get used to.
But these articles also told me there should be no problem for users using git to keep a local repository which updates from and pushes to our central svn system.
Conclusion : I'm not against switching to a DVCS, but I see no advantages with the current size of the active development team. The moment we have more active commiters that actually start getting trouble with bubvrsion, I'll be happy to reconsider this 'decision'.
Mark