On Wed, Nov 1, 2017 at 2:25 AM, Vincent Lefevre <vincent-...@vinc17.net> wrote: > On 2017-11-01 01:06:40 +0100, Vincent Lefevre wrote: >> Additional information: >> >> svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/fidelite@103183 >> >> works, but >> >> svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/fidelite@103182 >> >> yields the error. >> >> r103183 is just a change of the contents of this file (nothing else). > > Even simpler: > > joooj% svn ls -r103182 > file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@103182 > fidelite > joooj% svn ls -r103183 > file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@103183 > fidelite > joooj% svn ls -r103183 > file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@103182 > svn: E160016: Failure opening '/perso/tcl/fidelite' > svn: E160016: '/perso/tcl' is not a directory in filesystem > '99759db8-4ec0-0310-8bf9-df86780d22d8' > joooj% svn ls -r103182 > file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite@103183 > svn: E160016: Failure opening '/perso/tcl/fidelite' > svn: E160016: '/perso/tcl' is not a directory in filesystem > '99759db8-4ec0-0310-8bf9-df86780d22d8' > > Ditto between r103181 and r103182, while the commit r103182 occurred on > an unrelated path. > > So, it seems that for this file, if the operative revision is different > from the peg revision, this doesn't work. This is not what is described > at http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html and not > the behavior I can observe on the other files, even in the same > directory. So, this seems to be a bug. > > Note: "svnadmin verify /srv/d_joooj/home/svn/root" did not find any > issue. > > FYI, this is a Debian/stable (stretch) machine, with: > > svn, version 1.9.5 (r1770682) > compiled Aug 9 2017, 03:04:58 on x86_64-pc-linux-gnu
Most likely, /perso/tcl@103182 is not the same node as /perso/tcl@103183 and /perso/tcl@103181. I suppose you should be able to see this in the history, with an 'svn log -v' of the root directory: 103182 should show an 'R' for /perso/tcl, meaning it was Replaced by another node, not historically related to /perso/tcl before. And 103183 replaced it again with a copy of the original node. That would mean that the node with path /perso/tcl in r103182 is different from the one before and after it. So /perso/tcl@103183 does not exist in 103182. Could that be the case? If so, it's possible that this is working as designed. -- Johan