You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jelmer Vernooij <je...@samba.org> on 2006/06/14 19:05:54 UTC
[PATCH] More tests for the svn.wc Python bindings
Hi,
[[[
More test coverage for the svn.wc Python bindings.
* subversion/bindings/swig/python/tests/wc.py
(setUp): Acquire write lock on wc
(tearDown): Explicitly close wc
(test_lock): Add tests for add_lock and remove_lock
(test_version): Add test for version()
(test_is_adm_dir): Add test for is_adm_dir()
(test_get_adm_dir): Add test for get_adm_dir()
(test_set_adm_dir): Add test for set_adm_dir()
(test_init_traversal_info): Add test for init_traversal_info()
(test_create_notify): Add test for create_notify()
(test_check_wc): Add test for test_wc()
]]]
Cheers,
Jelmer
--
Jelmer Vernooij <je...@samba.org> - http://samba.org/~jelmer/
Re: [PATCH] More tests for the svn.wc Python bindings
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Thu, 15 Jun 2006 00:35:54 +0530, Jelmer Vernooij <je...@samba.org>
wrote:
> Hi,
>
> [[[
> More test coverage for the svn.wc Python bindings.
>
> * subversion/bindings/swig/python/tests/wc.py
> (setUp): Acquire write lock on wc
> (tearDown): Explicitly close wc
> (test_lock): Add tests for add_lock and remove_lock
> (test_version): Add test for version()
> (test_is_adm_dir): Add test for is_adm_dir()
> (test_get_adm_dir): Add test for get_adm_dir()
> (test_set_adm_dir): Add test for set_adm_dir()
> (test_init_traversal_info): Add test for init_traversal_info()
> (test_create_notify): Add test for create_notify()
> (test_check_wc): Add test for test_wc()
>
> ]]]
>
Why is the class called SubversionRepositoryTestCase? Shouldn't it be
SubversionWorkingCopyTestCase?
Also, am not sure about this, but wont it be much clearer, if the log file
referred to the functions with the class.function() convention?
btw, could you pl. attach the patches with a .txt extension. Thanks.
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] More tests for the svn.wc Python bindings
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/14/06, Jelmer Vernooij <je...@samba.org> wrote:
> On Wed, 2006-06-14 at 15:14 -0400, Garrett Rooney wrote:
> > On 6/14/06, Jelmer Vernooij <je...@samba.org> wrote:
> > > (test_check_wc): Add test for test_wc()
> >
> > It looks like this will break on builds from a tarball, as opposed to
> > checked out from svn. Or does the test framework chdir into a working
> > copy it checks out or something like that?
> Yes, self.path gets set to a temporary directory that contains a working
> copy made from an example repository (see setUp(), which does a checkout
> and sets self.path).
Ahh, cool. Committed in r20102.
Thanks!
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] More tests for the svn.wc Python bindings
Posted by Jelmer Vernooij <je...@samba.org>.
On Wed, 2006-06-14 at 15:14 -0400, Garrett Rooney wrote:
> On 6/14/06, Jelmer Vernooij <je...@samba.org> wrote:
> > (test_check_wc): Add test for test_wc()
>
> It looks like this will break on builds from a tarball, as opposed to
> checked out from svn. Or does the test framework chdir into a working
> copy it checks out or something like that?
Yes, self.path gets set to a temporary directory that contains a working
copy made from an example repository (see setUp(), which does a checkout
and sets self.path).
Cheers,
Jelmer
--
Jelmer Vernooij <je...@samba.org> - http://samba.org/~jelmer/
Re: [PATCH] More tests for the svn.wc Python bindings
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/14/06, Jelmer Vernooij <je...@samba.org> wrote:
> Hi,
>
> [[[
> More test coverage for the svn.wc Python bindings.
>
> * subversion/bindings/swig/python/tests/wc.py
> (setUp): Acquire write lock on wc
> (tearDown): Explicitly close wc
> (test_lock): Add tests for add_lock and remove_lock
> (test_version): Add test for version()
> (test_is_adm_dir): Add test for is_adm_dir()
> (test_get_adm_dir): Add test for get_adm_dir()
> (test_set_adm_dir): Add test for set_adm_dir()
> (test_init_traversal_info): Add test for init_traversal_info()
> (test_create_notify): Add test for create_notify()
These all look fine...
> (test_check_wc): Add test for test_wc()
It looks like this will break on builds from a tarball, as opposed to
checked out from svn. Or does the test framework chdir into a working
copy it checks out or something like that?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] More tests for the svn.wc Python bindings
Posted by David James <dj...@collab.net>.
On 6/15/06, Madan U Sreenivasan <ma...@collab.net> wrote:
> > pool=NULL is not a valid argument to create_svn_repos_t or
> > svn_repos_create.
>
> Is it? svn.repos.create() complains that it needs 5 parameters as input,
> when I give less than that. I cant figure out which five... Also, there is
> no apr_pool_create() function in svn.core (pool related functions are
> documented as deprecated)... so how do we create a pool to be passed to
> svn.repos.create()?
The signature for svn.repos.create in the Python bindings is:
new_repos = svn.repos.create(path, unused_1, unused_2, config, fs_config, pool)
In the Python bindings, the pool argument is optional. If you do not
specify it, a temporary pool will be generated for you automatically.
To generate a new pool, use the svn.core.Pool() function. Pools are
only needed in the Python bindings if you want to have fine-grained
control over how Python manages memory, which you usually do not need.
On the other hand, in C, the 'Pool' argument is not optional, and must
be specified. If you supply 'NULL' as the pool value, you will likely
provoke a segfault.
In general, the differences between the regular Subversion library and
the Python bindings are not very well documented, so you will often be
left guessing while you are using the bindings. Still, guessing isn't
that bad -- you can often guess how a function works by looking at its
header and figuring out what its 'input' and 'output' parameters are.
Here's a conversion rule. In C, you might see:
svn_error_t * svn_lib_function(svn_foo_t **output1, svn_foo_t
*input1, svn_foo_t *input2, svn_foo_t **output2, apr_pool_t *pool)
In Python, this converts to:
output1, output2 = svn.lib.function(input1, input2, pool)
... where the "pool" argument is optional, and should probably be left
out in typical usage.
Note that output arguments in C tend to be doubly indirect pointers
(i.e. two asteriks).
For examples of scripts which use the Python bindings, see the tools
and contrib directories. If you're looking to write new test scripts,
I'd recommend looking at those scripts first, and checking what
functionality is exercised by those scripts (in tools and contrib)
that is not yet exercised by our test suite.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] More tests for the svn.wc Python bindings
Posted by Madan U Sreenivasan <ma...@collab.net>.
On Fri, 16 Jun 2006 08:05:49 +0530, David James <dj...@collab.net> wrote:
>> Madan U Sreenivasan wrote:
[snip]
>> ---------------------8<---------------------------------8<------------------
>> > madan@madan ~/wc/trunk $ gdb --args python2.4
>> > ./subversion/bindings/swig/python/tests/wc.py
>> > #0 0x4048180e in apr_palloc () from /usr/lib/libapr-0.so.0
>> > #1 0x4066f8dc in create_svn_repos_t (path=0x403ef3c4
>> > "/tmp/trac-svnrepos", pool=0x0) at repos.c:1540
>> > #2 0x4066fc00 in svn_repos_create (repos_p=0x0, path=0x403ef3c4
>> > "/tmp/trac-svnrepos", unused_1=0x402b90ac "",
>> > unused_2=0x402b90ac "", config=0x0, fs_config=0x0, pool=0x0) at
>> > repos.c:1664
>> > #3 0x408f368a in ?? () from
>> > /usr/lib/python2.4/site-packages/libsvn/_repos.so
>
> Oops. You're using an old version of the Python bindings with a new
> version of Subversion. I can tell this from the stack trace because
> your Subversion build has debug symbols but your Python bindings build
> does not. Also, I can see that you're running Python bindings from
> '/usr/lib', and it is unusual to keep your trunk bindings in
> '/usr/lib'.
yeah... I just noticed... how come? lemme check... thanks for pointing
out, Garrett..
> Madan, have you tried running the regular 'make check-swig-py' target?
> This target automatically sets up your Python path so that the tests
> will run with the version of the Python bindings in your build tree.
> You may also need to run 'make clean-swig && ./configure' if you want
> to get a completely clean build.
Will do this...
>> > I will try with my laptop at office today... looking at the bt, I
>> > suspect linkages with older versions of libapr... what do you think?
>> I'm not sure - if pool=NULL is a valid argument to create_svn_repos_t(),
>> then at least the Python bindings are not to blame. This must've been
>> broken longer though - this is code that's being called from the trac
>> test cases.
>
> pool=NULL is not a valid argument to create_svn_repos_t or
> svn_repos_create.
Is it? svn.repos.create() complains that it needs 5 parameters as input,
when I give less than that. I cant figure out which five... Also, there is
no apr_pool_create() function in svn.core (pool related functions are
documented as deprecated)... so how do we create a pool to be passed to
svn.repos.create()?
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] More tests for the svn.wc Python bindings
Posted by David James <dj...@collab.net>.
> Madan U Sreenivasan wrote:
> > Why is the class called SubversionRepositoryTestCase? Shouldn't it be
> > SubversionWorkingCopyTestCase?
Good point. Yeah, that'd be better.
> > Also, am not sure about this, but wont it be much clearer, if the log file
> > referred to the functions with the class.function() convention?
If the file in question contains only one class, you can just use the
function name.
> > ---------------------8<---------------------------------8<------------------
> > madan@madan ~/wc/trunk $ gdb --args python2.4
> > ./subversion/bindings/swig/python/tests/wc.py
> > #0 0x4048180e in apr_palloc () from /usr/lib/libapr-0.so.0
> > #1 0x4066f8dc in create_svn_repos_t (path=0x403ef3c4
> > "/tmp/trac-svnrepos", pool=0x0) at repos.c:1540
> > #2 0x4066fc00 in svn_repos_create (repos_p=0x0, path=0x403ef3c4
> > "/tmp/trac-svnrepos", unused_1=0x402b90ac "",
> > unused_2=0x402b90ac "", config=0x0, fs_config=0x0, pool=0x0) at
> > repos.c:1664
> > #3 0x408f368a in ?? () from
> > /usr/lib/python2.4/site-packages/libsvn/_repos.so
Oops. You're using an old version of the Python bindings with a new
version of Subversion. I can tell this from the stack trace because
your Subversion build has debug symbols but your Python bindings build
does not. Also, I can see that you're running Python bindings from
'/usr/lib', and it is unusual to keep your trunk bindings in
'/usr/lib'.
Madan, have you tried running the regular 'make check-swig-py' target?
This target automatically sets up your Python path so that the tests
will run with the version of the Python bindings in your build tree.
You may also need to run 'make clean-swig && ./configure' if you want
to get a completely clean build.
> > I will try with my laptop at office today... looking at the bt, I
> > suspect linkages with older versions of libapr... what do you think?
> I'm not sure - if pool=NULL is a valid argument to create_svn_repos_t(),
> then at least the Python bindings are not to blame. This must've been
> broken longer though - this is code that's being called from the trac
> test cases.
pool=NULL is not a valid argument to create_svn_repos_t or svn_repos_create.
> I'm using libapr-1 (you appear to be using libapr-0), so you might want
> to try that version. Is subversion supposed to work with any particular
> version of libapr or should any do?
Subversion should work with either libapr-1 or libapr-0.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] More tests for the svn.wc Python bindings
Posted by Jelmer Vernooij <je...@samba.org>.
On Fri, 2006-06-16 at 11:35 +0530, Madan U Sreenivasan wrote:
> On Fri, 16 Jun 2006 05:27:34 +0530, Jelmer Vernooij <je...@samba.org>
> wrote:
> ---------------------8<---------------------------------8<------------------
> madan@madan ~/wc/trunk $ gdb --args python2.4
> ./subversion/bindings/swig/python/tests/wc.py
> GNU gdb 6.4
> Copyright 2005 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-pc-linux-gnu"...(no debugging symbols
> found)
> Using host libthread_db library "/lib/libthread_db.so.1".
>
> (gdb) r
> Starting program: /usr/bin/python2.4
> ./subversion/bindings/swig/python/tests/wc.py
> (no debugging symbols found)
> (no debugging symbols found)
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 7355)]
> start of SubversionRepositoryTestSetup
> after dumpfile open
> After tearDown
> Before creating repos at :/tmp/trac-svnrepos:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 7355)]
> 0x4048180e in apr_palloc () from /usr/lib/libapr-0.so.0
> (gdb) bt
> #0 0x4048180e in apr_palloc () from /usr/lib/libapr-0.so.0
> #1 0x4066f8dc in create_svn_repos_t (path=0x403ef3c4
> "/tmp/trac-svnrepos", pool=0x0) at repos.c:1540
> #2 0x4066fc00 in svn_repos_create (repos_p=0x0, path=0x403ef3c4
> "/tmp/trac-svnrepos", unused_1=0x402b90ac "",
> unused_2=0x402b90ac "", config=0x0, fs_config=0x0, pool=0x0) at
> repos.c:1664
> #3 0x408f368a in ?? () from
> /usr/lib/python2.4/site-packages/libsvn/_repos.so
> #4 0xbffaf8dc in ?? ()
> #5 0x403ef3c4 in ?? ()
> #6 0x402b90ac in ?? ()
> #7 0x402b90ac in ?? ()
> #8 0x00000000 in ?? ()
> (gdb) c
> Continuing.
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> (gdb)
> ---------------------8<---------------------------------8<------------------
>
> PS : I have put some simple print statements, whose output you will see
> just before the SIGSEGV...
>
> I will try with my laptop at office today... looking at the bt, I
> suspect linkages with older versions of libapr... what do you think?
I'm not sure - if pool=NULL is a valid argument to create_svn_repos_t(),
then at least the Python bindings are not to blame. This must've been
broken longer though - this is code that's being called from the trac
test cases.
I'm using libapr-1 (you appear to be using libapr-0), so you might want
to try that version. Is subversion supposed to work with any particular
version of libapr or should any do?
Cheers,
Jelmer
--
Jelmer Vernooij <je...@samba.org> - http://samba.org/~jelmer/