Re: 13rc7 checks on OSX 10.4.3 ... one 'FAIL' left

On Thu, 22 Dec 2005, OpenMacNews wrote:
...
> ln -sf libsvnjavahl-1.dylib subversion/bindings/java/javahl/native/.libs/libsvnjavahl-1.jnilib
> /Library/Java/Home/bin/java
> - -Djava.library.path=subversion/bindings/java/javahl/native/.libs:/usr/local/subversion13x/lib
> - -classpath subversion/bindings/java/javahl/classes:/usr/local/lib/java/junit.jar
> org.tigris.subversion.javahl.tests.BasicTests
> .......................F....
> Time: 91.776
> There was 1 failure:
> 1)
> testBasicLocking(org.tigris.subversion.javahl.tests.BasicTests)junit.framework.AssertionFailedError:
> file should be read only now expected:<false> but was:<true>
> at org.tigris.subversion.javahl.tests.BasicTests.testBasicLocking(BasicTests.java:1357)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at org.tigris.subversion.javahl.tests.BasicTests.main(BasicTests.java:69)
>
> FAILURES!!!
> Tests run: 27, Failures: 1, Errors: 0
>
>
> *which* file perm is being 'complained' abt? or is something else at hand?

The test is complaining about the file "/A/mu" in the JavaHL test
code's working copy.

This sounds related to issue #2306, which was actually reported only
on Windows in the 1.3 release stream. The issue has some comments
about other OSes, but those are related to the working copy operation
logging code which was introduced on the trunk after 1.3 branched off.

Here's the code snippet which is being run. The last line shown is
triggering the failure:

        client.propertySet(thisTest.getWCPath()+"/A/mu",
                           PropertyData.NEEDS_LOCK, "*", false);

        addExpectedCommitItem(thisTest.getWCPath(),
                thisTest.getUrl(), "A/mu",NodeKind.file,
                CommitItemStateFlags.PropMods);
        assertEquals("bad revision number on commit", 2,
                     client.commit(new String[] {thisTest.getWCPath()},
                                   "message", true));
        File f = new File(thisTest.getWCPath()+"/A/mu");
        assertEquals("file should be read only now", false, f.canWrite());

After committing a file with the "svn:needs-lock" property set (which
is what's happening above), that file is expected to be set read-only
by the working copy library. This is roughly the equivalent of
someone else locking a file in the repository, then you updating your
working copy and svn noticing that one of your files is locked. In
both cases, since you don't own the lock token for that file, it
should be read-only within your WC.

--
Daniel Rall