Hello, Denis Arnaud wrote:
> In case, at some point, you agree to migrate to Subversion, This is being considered for a long time already, but still without any clear outcome. :-) > I shall be > able to maintain SOCI from work What does prevent you from using CVS? > Moreover, in case you agree, I shall convert the tests so that they use > CPPUnit, I think there is no need to do it. The current test structure is appropriate and there is no clear benefit from changing it to anything else. Please note that the test program gives a "binary" outcome: it either works or it fails. There is no granularity finer than this and there is no need for it either. This means that you can treat the whole test as a single "test case". > so that we can monitor the quality with CruiseControl. Every external tool should be able to accommodate the complete program. What does prevent the CruiseControl to run the test as a whole and report success/failure based on what the test program returns? > We use > that stack, namely CPPUnit and CruiseControl, at work for several > projects. Please note that other people might use other "stacks" and therefore this argument is not universal. > As for the sustainability of the packaging for Fedora, I'm close to have > SOCI officially integrated into that distribution. Congratulations! Please let us know when this becomes official, so that we can put appropriate information on the SOCI web page. > However, in case you agree to integrate those few changes, it will > greatly simplify my work of packager after that. Until then, I must > spend a lot of time and energy to keep both versions (CVS and SVN) > synchronised... Please note that the development of SOCI is not very dynamic (does it mean that the project is mature?), so synchronizing several repositories several times per year does not sound like a big issue. Note also that you will most likely use your own repository at work (SVN?) *anyway*, mainly due to the specific requirements of your local work environment, and you will therefore need to access two repositories whatever they are - migrating to SVN at our side will not make your life any easier. Is that right? > PS: I'm more a developer than a packager (so, I can of course contribute > to the C++ code as well) Very good! Can you identify some area of SOCI that would be most interesting for you? As you noticed, the ODBC backend is lagging behind a bit, there is also always a need for new backends (native MS SQL?). If you have been following this list recently, you might have also noticed that there is an interest in support for short binary objects (instead of BLOBs). On a more exotic side, there is also a space for binding to other languages, like Python - the basic infrastructure is already in place and such an extension would allow those developers who use other languages to benefit from a coherent database access layer instead of using separate library in each programming language. Please feel free to explore and let us know if you find something of particular interest to you. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
