Maciej Sobczak wrote: > 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?
I believe my opinion well-known ;-) though it isn't important. The only think that makes troubles is testing on Windows because CVS authentication on SF.net requires me to load pageant + WinCVS + manually select SSH key for pageant + setup key in SF.net (once, but I've not done it yet). >> 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". I like current tests, except the lack of central configuration so I could put all connection settings to soci_test.conf and then run all-at-once using make check. Talking about CppUnit, *if* SOCI would need a unit test engine, TUT is better - only a few header files, only templates, very light but powerful: http://tut-framework.sourceforge.net/ I use TUT in two projects: http://trac.osgeo.org/geos and http://liblas.org There was plan to apply SOCI to Boost, then it would be required to use Boost Test framework. Anyway, this idea has been deferred. >> 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? Also, why not to consider SOCI as external/3rd-party dependency and do not keep it in local repo? Denis, do you maintain all other dependencies locally? If you do, I'd say it's a popular practice in many shops, but then you have to agree it will cost you time. >> 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. I second Maciek's proposal. Python bindings would be awesome! However, I'd strongly encourage to use Boost Python instead of SWIG or c-types. We (SOCI) already uses Boost, so we agreed on Boost as a dependency. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org ------------------------------------------------------------------------------ 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
