> -----Original Message-----
> From: hyrum_at_hyrumwright.org [mailto:hyrum_at_hyrumwright.org] On Behalf Of
> Hyrum Wright
> Sent: maandag 30 augustus 2010 21:43
> To: Subversion Development
> Cc: commits
> Subject: Re: svn commit: r990916 - in
> /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp
> ClientContext.h
>
> On Mon, Aug 30, 2010 at 2:37 PM, <hwright_at_apache.org> wrote:
> > Author: hwright
> > Date: Mon Aug 30 19:37:05 2010
> > New Revision: 990916
> >
> > URL: http://svn.apache.org/viewvc?rev=990916&view=rev
> > Log:
> > JavaHL: Create a persistent C client context, in order to reuse the
> working
> > copy context between client API invocations.
> >
> > Note: This introduces a test failure which I believe to be a
> manifestation of
> > a bug in wc-ng.
>
> For the interested, this is the test failure:
>
> [[[
> hwright_at_orac:~/dev/svn-trunk2$ make check-javahl
> /usr/lib/jvm/java-6-openjdk//bin/java
> "-Dtest.rootdir=/home/hwright/dev/svn-
> trunk2/subversion/bindings/javahl/test-work"
> "-Dtest.srcdir=/home/hwright/dev/svn-trunk2/subversion/bindings/javahl"
> "-Dtest.rooturl=" "-Dtest.fstype="
> -
> Djava.library.path=subversion/bindings/javahl/native/.libs:/usr/local/l
> ib
> -classpath subversion/bindings/javahl/classes:/home/hwright/dev/svn-
> trunk2/subversion/bindings/javahl/src:/usr/share/java/junit.jar
> "-Dtest.tests=" org.apache.subversion.javahl.RunTests
> ......................E...................
> ...........
> Time: 26.083
> There was 1 error:
> 1)
> testBasicRevert(org.apache.subversion.javahl.BasicTests)org.apache.subv
> ersion.javahl.ClientException:
> Attempted to lock an already-locked dir
> svn: Working copy
> '/home/hwright/dev/svn-trunk2/subversion/bindings/javahl/test-
> work/working_copies/basic_test19/X'
> locked
> SQLite error
> svn: disk I/O error
> svn: disk I/O error
> svn: cannot rollback - no transaction is active
> Working copy not locked; this is probably a bug, please report
> svn: Working copy not locked at
> '/home/hwright/dev/svn-trunk2/subversion/bindings/javahl/test-
> work/working_copies/basic_test19/X'.
>
> at native.subversion.libsvn_wc(wc_db.c:8481)
> at native.subversion.libsvn_subr(sqlite.c:118)
> at native.subversion.libsvn_subr(sqlite.c:513)
> at native.subversion.libsvn_subr(sqlite.c:211)
> at native.subversion.libsvn_wc(wc_db.c:8276)
> at native.subversion.libsvn_subr(sqlite.c:118)
> at native.subversion.libsvn_wc(lock.c:1655)
> at native.subversion.libsvn_wc(lock.c:1639)
> at native.subversion.libsvn_wc(lock.c:1744)
> at native.subversion.libsvn_wc(lock.c:1844)
> at native.subversion.libsvn_client(revert.c:176)
> at org.apache.subversion.javahl.SVNClient.revert(Native Method)
> at
> org.apache.subversion.javahl.BasicTests.testBasicRevert(BasicTests.java
> :1332)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
> va:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
> rImpl.java:43)
> at org.apache.subversion.javahl.RunTests.main(RunTests.java:116)
>
> FAILURES!!!
> Tests run: 52, Failures: 0, Errors: 1
>
> make: *** [check-javahl] Error 1
> hwright_at_orac:~/dev/svn-trunk2$
> ]]]
>
> I believe it to be a legitimate bug, not only because the client APIs
> are being used in a completely reasonable way, but also because the
> output told me so. :)
The problem with this test is that we still have the X/.svn/wc.db handle
open while we delete X (referenced from the pdh's wcroot). (This test does
this to try some missing directory behavior).
We then try to store a lock in wc.db (to perform the revert), which makes
SQLite create a transaction log file next to wc.db. But then it finds that
this directory no longer exists, so it can't create the file.
On Windows the directory is not deleted because we still have that file
open. (File.delete() returns false in SVNTest.removeDirOrFile(), but we
don't check the result there).
But as this doesn't give the expected result (X is unmodified there), the
test fails a few lines later.
This specific issue is fixed once we move to SingleDB, but the problem that
we can delete databases that we have open will stay (on non Windows
systems).
Bert
Received on 2010-08-31 11:55:05 CEST