Re: JavaHL ISVNClient.vacuum yields assertion failed (1.9.2)

2015-10-23 Thread Christian K.
[answer directly to users@subversion.apache.org, seems like with Google Groups and subversion_us...@googlegroups.com things get lost] Hello Philip, the path being used is of the form C:\Temp\wc, it has been generated using File.getAbsolutePath(). The error was observed on a Windows 7 x64 system

JavaHL ISVNClient.vacuum yields assertion failed (1.9.2)

2015-10-23 Thread christian . k . 2510
Hello, trying to use the new ISVNClient.vacuum method from the JavaHL binding throws an exception pointing to the following assertion failure: svn: In file '..\..\..\subversion\libsvn_client\cleanup.c' line 252: assertion failed (svn_dirent_is_absolute(dir_abspath)) The exception is thrown even

Re: Changing external to sub-directory yields W155007 and E205011

2015-04-13 Thread Christian K.
Dear all, it would be helpful if someone could reproduce/confirm the behavior. This would be an important step towards a bug report. Thanks and best regards, Christian On Wed, Apr 8, 2015 at 9:40 PM, Christian K. wrote: > Hello Bert, > > thanks for your reply. From my understanding

Re: Changing external to sub-directory yields W155007 and E205011

2015-04-08 Thread Christian K.
n your working copy… they are a higher > level abstraction and a working copy by itself) > > > > > > As far as I can tell this works as expected. > > > > Bert > > > > *From:* Christian K. [mailto:christian.k.2...@gmail.com] > *Sent:*

Changing external to sub-directory yields W155007 and E205011

2015-04-08 Thread Christian K.
Dear all, using svn 1.8.11 changing an existing svn:externals property to a sub-directory thereof will result in an "... is not a working copy root" (combination of W20, W155007 and E205011). The attached sequence of commands [1] will reproduce the behavior from scratch (Windows batch syntax).

Reproducible VM crash using JavaHL

2014-04-10 Thread Christian K.
Hello, it seems like that I'm facing a bug in JavaHL which causes a reproducible VM crash. As per "Getting involved" [1] I'm reporting it here. The crash is caused if an implementation of org.apache.subversion.javahl.callback.ConflictResolverCallback throws a RuntimeException from within the inte