[Skliarouk Arieh] > libapr0 2.0.55-3 > libc6 2.3.5-6 > libdb4.3 4.3.28-3 > libxml2 2.6.22-1 > zlib1g 1.2.3-4
Thanks - I'm running the same of everything except libc6 2.3.5-8.1, but that really doesn't seem likely to be the problem. I still can't reproduce the problem. I tried nesting 30 directories with much longer names. Before you upgraded to subversion 1.3.0, I imagine you had matching versions of subversion and libsvn0 - true? (The dependencies don't *quite* enforce this.) Also, I'd still like to know your processor architecture. I'm running i386, which is very forgiving of certain data errors. Architectures such as sparc and alpha are much less so. > One more hint to this puzzle: Before the upgrade, whenever I tried to > do remote checkout over ssh (svn co > svn+ssh://[EMAIL PROTECTED]/svnroot/blahblah), from client machine with > subversion 1.2.3dfsg1-3, it also failed. Not surprising - most of the same code paths are exercised. > After the upgrade (on the server) it works, so the bug seemingly sits > at the server side code. So whatever it is seems to be in the repository access backends rather than the working copy frontend. You can probably verify this with 'svn diff -r0:HEAD file://$HOME/test.svn' or similar, on the server. (That deals purely in the repository access backends.) Also, just to satisfy my curiosity, can you try this with file:///? subversion 1.2.3dfsg1-3 libsvn0 1.3.0-1 This should work fine, as the bug is probably in libsvn0. > IMHO, it worthwhile to track the bug, even if it is not seen in > latests release. Besides potential buffer overrun, SVN is too > important for allow bugs to leave by themselves. Right. Thanks for working with me, Peter
signature.asc
Description: Digital signature
