Hello,
Maciej Sobczak 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. :-)
>
> A few advantages are:
- atomic commits (each commit is more or less like a CVS tag, without the
heavyness of that latter);
- easyness of branching and merging (server-side, that operation is
cheap, as it is relying on soft copies) [as said above, tagging is of course
possible, but almost useless];
- versionning of meta-data (allowing for instance to rename files, while
keeping the change logs, allowing to version directories, allowing to
version the file properties (e.g., execution rights), etc.);
- easy maintenance (back-up, import/export, synchronisation, etc.);
- same command line options as for CVS (so, for CVS users, there is no
big change: just replace "cvs" by "svn" in your commands);
- native support for binary files (without having to specify mannually
whether the added file is binary or not);
- and, last but not least, the native support of both http and https,
allowing working on projects from behind firewalls and other proxies (which
is not possible with CVS).
> I shall be able to maintain SOCI from work
>
> What does prevent you from using CVS?
>
> Our company, like many others, closes all the ports to outside, except of
course ports 80 (http) and 443 (https). SSH port (21) is closed/forbidden,
and SSH-tunnelling is therefore not a work-around. The only way fro me to
work on the SOCI CVS trunk within my company is to do an export at home, to
bring it at work and to synchronise it with the codebase within my company,
every time an update is made... And, if I contribute, I have to take that
contribution back to home... So, for me, SVN is not an option, it is like
mandatory. Then, I have to spend a lot of time synchronising code during the
week-end. And I believe that I could spend that time doing more fruitful
things. Hopefully, as you said, the product is now mature, and there are not
so many changes :)
> 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".
>
> CPPUnit just produces a standard output, from those tests. "Migrating tests
to CPPUnit" just means adding the existing test functions into CPPUnit
macros, something like:
-----------------------
CPPUNIT_ASSERT_NO_THROW (test1(););
CPPUNIT_ASSERT_NO_THROW (test2(););
-----------------------
and adding the TESTS target to the Makefile.am:
-----------------------
check_PROGRAMS = test-mysql
TESTS = $(check_PROGRAMS)
-----------------------
That way, the existing test binaries still exist, and can be used as before,
while all the tests can be checked by the dedicated "make check" target
(standard test target within the GNU Autotools). Another standard target is
"make distcheck", allowing to check that all the tests of the released
tar-ball (produced by "make dist") are successfull. That is kind of
"integrated Q&A process".
> 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?
>
> CruiseControl natively uses Ant and JUnit, which produces XML output. A
small modification of CPPUnit (done here:
http://opentrep.svn.sourceforge.net/viewvc/opentrep/trunk/opentrep/test/com/)
allows to produce the same XML output, allowing to run natively
CruiseControl (i.e., without any modification).
Note that what I suggest is rather an addition than a migration, as the
existing test binaries will remain untouched.
> 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.
>
> That is right: others may use other stacks, meaning a still improved
quality of the code :)
> 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?
>
> Yes, of course, we use locally Subversion repositories at work, along with
plenty of other SCM (among which CVS, and even a proprietary SCM on top of
CVS). But the difficulty is not to work with several SCM types, it is to be
able to access them from work. For instance, we use RMOL (
http://sourceforge.net/projects/rmol) and OpenTREP (
http://sourceforge.net/projects/opentrep), which we can contribute to from
work. I'm not able to do that with SOCI, as I do not have access to the SOCI
CVS repository from work.
> 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 I'm more a Unix expert (I'm not at ease with MS environment and tools),
I'd rather contribute to MySQL, Oracle, PostgreSQL and SQLite. Also, I was
wondering whether some of you already thought to have SOCI be compatible
with memcached (http://code.google.com/p/memcached/)? I'm not sure it makes
sense, though :)
In summary, I propose:
- to create a SVN repository on SOCI's SourceForge account, wich will be
a duplicate of the CVS repository and co-exist with it [SourceForge allows
to have several repositories]. That will allow some of us to contribute to
the project from anywhere;
- on that SVN repository, to put some add-ons, such as i18n (PO files),
Manual and info pages, Doxygen-generated documentation, CPPUnit and/or TUT
tests, etc. Again, everything will be add-ons, and will not replace what
exists today. So, anyone not interested by those additional features will
have SOCI work as usual (binary tests, TCL build, static HTML documentation,
etc.).
That way, you'll be able to control that everything is compliant with your
tastes and goals, and the packaging, release, integration and tests will
become a snap.
[Of course, I can continue to work on my own repository (
http://opentrep.svn.sourceforge.net/viewvc/opentrep/trunk/soci/),
independantly from yours. But, technically, that would be a fork from your
project, and I'd rather, if possible, contributing to your project, instead
of to a fork]
Denis
------------------------------------------------------------------------------
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
