You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by hw...@apache.org on 2010/08/30 21:37:05 UTC
svn commit: r990916 - in
/subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp
ClientContext.h
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.
* subversion/bindings/javahl/native/ClientContext.h
(persistentCtx): New.
* subversion/bindings/javahl/native/ClientContext.cpp
(ClientContext): Populate the persistentCtx in the global pool on
construction.
(getContext): Reuse the persistent context, rather than create a new one.
Modified:
subversion/trunk/subversion/bindings/javahl/native/ClientContext.cpp
subversion/trunk/subversion/bindings/javahl/native/ClientContext.h
Modified: subversion/trunk/subversion/bindings/javahl/native/ClientContext.cpp
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/bindings/javahl/native/ClientContext.cpp?rev=990916&r1=990915&r2=990916&view=diff
==============================================================================
--- subversion/trunk/subversion/bindings/javahl/native/ClientContext.cpp (original)
+++ subversion/trunk/subversion/bindings/javahl/native/ClientContext.cpp Mon Aug 30 19:37:05 2010
@@ -29,6 +29,7 @@
#include "ClientContext.h"
#include "JNIUtil.h"
+#include "JNICriticalSection.h"
#include "Prompter.h"
#include "ClientNotifyCallback.h"
@@ -50,6 +51,11 @@ ClientContext::ClientContext()
m_commitMessage(NULL),
m_conflictResolver(NULL)
{
+ JNICriticalSection criticalSection(*JNIUtil::getGlobalPoolMutex());
+
+ /* Create a long-lived client context object in the global pool. */
+ SVN_JNI_ERR(svn_client_create_context(&persistentCtx, JNIUtil::getPool()),
+ );
}
ClientContext::~ClientContext()
@@ -67,8 +73,8 @@ ClientContext::getContext(const char *me
SVN::Pool *requestPool = JNIUtil::getRequestPool();
apr_pool_t *pool = requestPool->pool();
svn_auth_baton_t *ab;
- svn_client_ctx_t *ctx;
- SVN_JNI_ERR(svn_client_create_context(&ctx, pool), NULL);
+ svn_client_ctx_t *ctx = persistentCtx;
+ //SVN_JNI_ERR(svn_client_create_context(&ctx, pool), NULL);
const char *configDir = m_configDir.c_str();
if (m_configDir.length() == 0)
Modified: subversion/trunk/subversion/bindings/javahl/native/ClientContext.h
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/bindings/javahl/native/ClientContext.h?rev=990916&r1=990915&r2=990916&view=diff
==============================================================================
--- subversion/trunk/subversion/bindings/javahl/native/ClientContext.h (original)
+++ subversion/trunk/subversion/bindings/javahl/native/ClientContext.h Mon Aug 30 19:37:05 2010
@@ -49,6 +49,8 @@ class CommitMessage;
class ClientContext
{
private:
+ svn_client_ctx_t *persistentCtx;
+
std::string m_userName;
std::string m_passWord;
std::string m_configDir;
RE: svn commit: r990916 - in /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp ClientContext.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: dinsdag 31 augustus 2010 10:26
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r990916 - in
> /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp
> ClientContext.h
>
> "Bert Huijben" <be...@qqmail.nl> writes:
>
> > (I see a completely different test failure on the Windows bot)
>
> On Linux I get the same as Hyrum.
>
> > Can you run this same test with single-db?
>
> In single-db on Linux I get 3 Failures rather than 1 Error:
>
> .....................F..F..F................
> .........
> Time: 139.136
> There were 3 failures:
> 1)
> testBasicRevert(org.tigris.subversion.javahl.BasicTests)junit.framework
> .AssertionFailedError: status not found in working copy: A/B/E/alpha
> at org.tigris.subversion.javahl.WC.check(WC.java:466)
> at
> org.tigris.subversion.javahl.SVNTests$OneTest.checkStatus(SVNTests.java
> :851)
> at
> org.tigris.subversion.javahl.SVNTests$OneTest.checkStatus(SVNTests.java
> :833)
> at
> org.tigris.subversion.javahl.BasicTests.testBasicRevert(BasicTests.java
> :1359)
> 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.tigris.subversion.javahl.RunTests.main(RunTests.java:116)
This looks like a similar error as the one I see on the Windows buildbot in
multi-db.
> 2)
> testBasicDelete(org.tigris.subversion.javahl.BasicTests)junit.framework
> .AssertionFailedError: removed versioned dir
> at
> org.tigris.subversion.javahl.BasicTests.testBasicDelete(BasicTests.java
> :1640)
> 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.tigris.subversion.javahl.RunTests.main(RunTests.java:116)
This might be checking multi-db behavior. It looks like it just deletes a
directory and expects missing data. (By just looking at the description)
> 3)
> testBasicNodeKindChange(org.tigris.subversion.javahl.BasicTests)junit.f
> ramework.AssertionFailedError: can change node kind
> at
> org.tigris.subversion.javahl.BasicTests.testBasicNodeKindChange(BasicTe
> sts.java:1743)
> 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.tigris.subversion.javahl.RunTests.main(RunTests.java:116)
And changing node kind is no problem with single-db.
>
> FAILURES!!!
> Tests run: 50, Failures: 3, Errors: 0
<snip> Rest of the response in a different thread.
Bert
Re: Recursive revert behavior
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/31/2010 05:10 AM, Bert Huijben wrote:
>> -----Original Message-----
>> From: Philip Martin [mailto:philip.martin@wandisco.com]
>> Sent: dinsdag 31 augustus 2010 10:26
>> To: dev@subversion.apache.org
>> Subject: Re: svn commit: r990916 - in
>> /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp
>> ClientContext.h
>>
>> "Bert Huijben" <be...@qqmail.nl> writes:
>>
>
> <snip> See original thread
>
>>
>>> The current recursive lock code for multi-db doesn't have stable
>> behavior
>>> over added and removed directories, while the single-db code has. I
>> didn't
>>> feel like reinventing a complete lock store system like the old
>> access
>>> batons just to fix these issues for multi-db. (Single-db has a real
>>> recursive lock, so it only has to delete the lock from the root)
>>
>> The recursive lock is a problem for non-recursive revert as it no
>> longer returns SVN_ERR_WC_NOT_LOCKED, see the XFail in revert_tests.py
>> (and our client explicitly checks for that error). We can fix the
>> recursive behaviour of revert, but can we fix the return value? Is it
>> acceptable to return SVN_ERR_WC_NOT_LOCKED when we have a recursive
>> lock?
>
> This is one of the revert tests if I remember correctly?
>
> I think we have to move these checks in the revert code instead of forcing
> old lock behavior. But I really don't know what we should do here, except
> for maybe revving svn_client_revertX(), to move the old behavior in the
> deprecated wrapper.
>
> For who doesn't know the full story: This is about
> * svn revert root-of-copy-operation
> vs
> * svn revert -R root-of-copy-operation
>
> With the new fully recursive lock behavior in all libsvn_client functions
> this 'svn revert WC-TREE' just works, but it is a big behavior change.
> And in this case the old behavior warned you before performing a lossy
> operation, which was kind of useful.
I think requiring -R for any deep revert makes sense and is the behavior
that users have grown to expect.
But why not at least make 'svn revert COPY-TARGET-DIR' do something useful,
such as revert any propchanges made to the copy target? It can even still
notify with a warning that the reversion wasn't deep, suggesting the
--recursive flag as we do today.
In other words, where today we see:
$ svn copy A A-copy
$ svn pset foo bar A-copy
$ svn revert A-copy
svn: Try 'svn revert --depth infinity' instead?
subversion/libsvn_wc/lock.c:952: (apr_err=155005)
svn: Unable to lock 'A-copy/B'
$
We might see:
$ svn copy A A-copy
$ svn pset foo bar A-copy
$ svn revert A-copy
Reverted property changes for 'Z'
svn: warning: Directory 'Z' contains additional changes; use 'svn \
revert --depth infinity' to revert the whole tree.
$
Just a thought.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Recursive revert behavior
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 08/31/2010 05:10 AM, Bert Huijben wrote:
>> -----Original Message-----
>> From: Philip Martin [mailto:philip.martin@wandisco.com]
>> Sent: dinsdag 31 augustus 2010 10:26
>> To: dev@subversion.apache.org
>> Subject: Re: svn commit: r990916 - in
>> /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp
>> ClientContext.h
>>
>> "Bert Huijben" <be...@qqmail.nl> writes:
>>
>
> <snip> See original thread
>
>>
>>> The current recursive lock code for multi-db doesn't have stable
>> behavior
>>> over added and removed directories, while the single-db code has. I
>> didn't
>>> feel like reinventing a complete lock store system like the old
>> access
>>> batons just to fix these issues for multi-db. (Single-db has a real
>>> recursive lock, so it only has to delete the lock from the root)
>>
>> The recursive lock is a problem for non-recursive revert as it no
>> longer returns SVN_ERR_WC_NOT_LOCKED, see the XFail in revert_tests.py
>> (and our client explicitly checks for that error). We can fix the
>> recursive behaviour of revert, but can we fix the return value? Is it
>> acceptable to return SVN_ERR_WC_NOT_LOCKED when we have a recursive
>> lock?
>
> This is one of the revert tests if I remember correctly?
>
> I think we have to move these checks in the revert code instead of forcing
> old lock behavior. But I really don't know what we should do here, except
> for maybe revving svn_client_revertX(), to move the old behavior in the
> deprecated wrapper.
>
> For who doesn't know the full story: This is about
> * svn revert root-of-copy-operation
> vs
> * svn revert -R root-of-copy-operation
>
> With the new fully recursive lock behavior in all libsvn_client functions
> this 'svn revert WC-TREE' just works, but it is a big behavior change.
> And in this case the old behavior warned you before performing a lossy
> operation, which was kind of useful.
I think requiring -R for any deep revert makes sense and is the behavior
that users have grown to expect.
But why not at least make 'svn revert COPY-TARGET-DIR' do something useful,
such as revert any propchanges made to the copy target? It can even still
notify with a warning that the reversion wasn't deep, suggesting the
--recursive flag as we do today.
In other words, where today we see:
$ svn copy A A-copy
$ svn pset foo bar A-copy
$ svn revert A-copy
svn: Try 'svn revert --depth infinity' instead?
subversion/libsvn_wc/lock.c:952: (apr_err=155005)
svn: Unable to lock 'A-copy/B'
$
We might see:
$ svn copy A A-copy
$ svn pset foo bar A-copy
$ svn revert A-copy
Reverted property changes for 'Z'
svn: warning: Directory 'Z' contains additional changes; use 'svn \
revert --depth infinity' to revert the whole tree.
$
Just a thought.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Recursive revert behavior
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
> This is one of the revert tests if I remember correctly?
Yes.
> I think we have to move these checks in the revert code instead of forcing
> old lock behavior. But I really don't know what we should do here, except
> for maybe revving svn_client_revertX(), to move the old behavior in the
> deprecated wrapper.
>
> For who doesn't know the full story: This is about
> * svn revert root-of-copy-operation
> vs
> * svn revert -R root-of-copy-operation
>
> With the new fully recursive lock behavior in all libsvn_client functions
> this 'svn revert WC-TREE' just works, but it is a big behavior change.
> And in this case the old behavior warned you before performing a lossy
> operation, which was kind of useful.
>
> For new code I think this kind of checks belong in the client (svn,
> TortoiseSVN, AnkhSVN, etc.) instead of in libsvn_wc or libsvn_client. But in
> this case it changes a lot of old code.
At present
svn_wc_revert4(root_of_copy, depth=empty)
succeeds and recursively reverts the copied tree. In 1.6
svn_wc_revert3(root_of_copy, depth=empty)
would fail with SVN_ERR_WC_NOT_LOCKED if the copied directory had
versioned subdirectories. (I've just realised that 1.6 is
inconsistent, it only errors on children that are directories not
children that are files.)
We could make revert with depth=empty fail on a copied tree unless the
tree is empty. If we do that it would probably fail with some sort of
depth error. I suppose svn_wc_revert3 could convert that to
SVN_ERR_WC_NOT_LOCKED for 1.6 compatibility?
--
Philip
RE: Recursive revert behavior (was: svn commit: r990916 )
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: dinsdag 31 augustus 2010 10:26
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r990916 - in
> /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp
> ClientContext.h
>
> "Bert Huijben" <be...@qqmail.nl> writes:
>
<snip> See original thread
>
> > The current recursive lock code for multi-db doesn't have stable
> behavior
> > over added and removed directories, while the single-db code has. I
> didn't
> > feel like reinventing a complete lock store system like the old
> access
> > batons just to fix these issues for multi-db. (Single-db has a real
> > recursive lock, so it only has to delete the lock from the root)
>
> The recursive lock is a problem for non-recursive revert as it no
> longer returns SVN_ERR_WC_NOT_LOCKED, see the XFail in revert_tests.py
> (and our client explicitly checks for that error). We can fix the
> recursive behaviour of revert, but can we fix the return value? Is it
> acceptable to return SVN_ERR_WC_NOT_LOCKED when we have a recursive
> lock?
This is one of the revert tests if I remember correctly?
I think we have to move these checks in the revert code instead of forcing
old lock behavior. But I really don't know what we should do here, except
for maybe revving svn_client_revertX(), to move the old behavior in the
deprecated wrapper.
For who doesn't know the full story: This is about
* svn revert root-of-copy-operation
vs
* svn revert -R root-of-copy-operation
With the new fully recursive lock behavior in all libsvn_client functions
this 'svn revert WC-TREE' just works, but it is a big behavior change.
And in this case the old behavior warned you before performing a lossy
operation, which was kind of useful.
For new code I think this kind of checks belong in the client (svn,
TortoiseSVN, AnkhSVN, etc.) instead of in libsvn_wc or libsvn_client. But in
this case it changes a lot of old code.
Bert
Re: svn commit: r990916 - in /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp ClientContext.h
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
> (I see a completely different test failure on the Windows bot)
On Linux I get the same as Hyrum.
> Can you run this same test with single-db?
In single-db on Linux I get 3 Failures rather than 1 Error:
.....................F..F..F................
.........
Time: 139.136
There were 3 failures:
1) testBasicRevert(org.tigris.subversion.javahl.BasicTests)junit.framework.AssertionFailedError: status not found in working copy: A/B/E/alpha
at org.tigris.subversion.javahl.WC.check(WC.java:466)
at org.tigris.subversion.javahl.SVNTests$OneTest.checkStatus(SVNTests.java:851)
at org.tigris.subversion.javahl.SVNTests$OneTest.checkStatus(SVNTests.java:833)
at org.tigris.subversion.javahl.BasicTests.testBasicRevert(BasicTests.java:1359)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.tigris.subversion.javahl.RunTests.main(RunTests.java:116)
2) testBasicDelete(org.tigris.subversion.javahl.BasicTests)junit.framework.AssertionFailedError: removed versioned dir
at org.tigris.subversion.javahl.BasicTests.testBasicDelete(BasicTests.java:1640)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.tigris.subversion.javahl.RunTests.main(RunTests.java:116)
3) testBasicNodeKindChange(org.tigris.subversion.javahl.BasicTests)junit.framework.AssertionFailedError: can change node kind
at org.tigris.subversion.javahl.BasicTests.testBasicNodeKindChange(BasicTests.java:1743)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.tigris.subversion.javahl.RunTests.main(RunTests.java:116)
FAILURES!!!
Tests run: 50, Failures: 3, Errors: 0
> The current recursive lock code for multi-db doesn't have stable behavior
> over added and removed directories, while the single-db code has. I didn't
> feel like reinventing a complete lock store system like the old access
> batons just to fix these issues for multi-db. (Single-db has a real
> recursive lock, so it only has to delete the lock from the root)
The recursive lock is a problem for non-recursive revert as it no
longer returns SVN_ERR_WC_NOT_LOCKED, see the XFail in revert_tests.py
(and our client explicitly checks for that error). We can fix the
recursive behaviour of revert, but can we fix the return value? Is it
acceptable to return SVN_ERR_WC_NOT_LOCKED when we have a recursive lock?
--
Philip
RE: svn commit: r990916 - in /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp ClientContext.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: hyrum@hyrumwright.org [mailto:hyrum@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, <hw...@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:
(I see a completely different test failure on the Windows bot)
Can you run this same test with single-db?
The current recursive lock code for multi-db doesn't have stable behavior
over added and removed directories, while the single-db code has. I didn't
feel like reinventing a complete lock store system like the old access
batons just to fix these issues for multi-db. (Single-db has a real
recursive lock, so it only has to delete the lock from the root)
Bert
RE: svn commit: r990916 - in /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp ClientContext.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: hyrum@hyrumwright.org [mailto:hyrum@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, <hw...@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@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@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
RE: svn commit: r990916 - in /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp ClientContext.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: hyrum@hyrumwright.org [mailto:hyrum@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, <hw...@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:
(I see a completely different test failure on the Windows bot)
Can you run this same test with single-db?
The current recursive lock code for multi-db doesn't have stable behavior
over added and removed directories, while the single-db code has. I didn't
feel like reinventing a complete lock store system like the old access
batons just to fix these issues for multi-db. (Single-db has a real
recursive lock, so it only has to delete the lock from the root)
Bert
Re: svn commit: r990916 - in /subversion/trunk/subversion/bindings/javahl/native:
ClientContext.cpp ClientContext.h
Posted by Hyrum Wright <hw...@apache.org>.
On Mon, Aug 30, 2010 at 2:37 PM, <hw...@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@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/lib
-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.subversion.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.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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@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. :)
-Hyrum
Re: svn commit: r990916 - in /subversion/trunk/subversion/bindings/javahl/native:
ClientContext.cpp ClientContext.h
Posted by Hyrum Wright <hw...@apache.org>.
On Mon, Aug 30, 2010 at 2:37 PM, <hw...@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@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/lib
-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.subversion.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.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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@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. :)
-Hyrum