Paul Burba wrote on Tue, Nov 16, 2010 at 17:55:30 -0500:
> As some of you know I've recently had some strange failures with the
> svnsync tests on both trunk and 1.6.x. All the tests started failing
> during setup when the stdout of svnsync init was lost, e.g.:
>
> [[[
> CMD: svnsync.exe initialize
> "file:///C%3A/SVN/src-branch-1.6.x/Debug/subversion/tests/cmdline/svn-test-work/repositories/svnsync_tests-1-1"
> "file:///C%3A/SVN/sr
> c-branch-1.6.x/Debug/subversion/tests/cmdline/svn-test-work/repositories/svnsync_tests-1"
> --username jrandom --password rayjandom --config-dir "C:\SVN\src-branc
> h-1.6.x\Debug\subversion\tests\cmdline\svn-test-work\local_tmp\config"
> <TIME = 0.314000>
> EXCEPTION: SVNUnexpectedStdout: []
It's expecting a "Copied r0 revprops" line. If you run that 'svnsync init'
command manually, does it print that line?
> Traceback (most recent call last):
> File "C:\SVN\src-branch-1.6.x\subversion\tests\cmdline\svntest\main.py",
> line 1226, in run
> rc = self.pred.run(**kw)
> File "C:\SVN\src-branch-1.6.x\subversion\tests\cmdline\svntest\testcase.py",
> line 121, in run
> return self.func(sandbox)
> File "C:\SVN\src-branch-1.6.x\\subversion\tests\cmdline\svnsync_tests.py",
> line 193, in copy_and_modify
> run_test(sbox, "copy-and-modify.dump")
> File "C:\SVN\src-branch-1.6.x\\subversion\tests\cmdline\svnsync_tests.py",
> line 157, in run_test
> run_init(dest_sbox.repo_url, repo_url)
> File "C:\SVN\src-branch-1.6.x\\subversion\tests\cmdline\svnsync_tests.py",
> line 100, in run_init
> raise SVNUnexpectedStdout(output)
> SVNUnexpectedStdout: []
> FAIL: svnsync_tests.py 1: copy and modify
> ]]]
> Then, on a lark, I tried to build 1.6.x with the --disable-shared
> option. The tests passed. Because this problem seemed to come and go
> I tired a clean rebuild with shared libs. It failed. 3 times I tried
> shared/static libs, each time the static lib build passed, the shared
> lib build failed.
>
> Does anyone have any idea what could be the problem? Obviously I'm
> using --disable-shared for the time being, but would like to figure
> out what is happening here.
>
I don't know, but perhaps change SVN_VER_MINOR/SVN_VER_TAG to ensure the
DLLs you load are the right ones?
> Thanks,
>
> Paul
Received on 2010-11-17 14:34:57 CET