On Wed, Nov 1, 2017 at 2:25 AM, Vincent Lefevre <vincent-svn_at_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_at_103183
>>
>> works, but
>>
>> svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/fidelite_at_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_at_103182
> fidelite
> joooj% svn ls -r103183 file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite_at_103183
> fidelite
> joooj% svn ls -r103183 file:///srv/d_joooj/home/svn/root/perso/tcl/fidelite_at_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_at_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_at_103182 is not the same node as
/perso/tcl_at_103183 and /perso/tcl_at_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_at_103183 does
not exist in 103182. Could that be the case?
If so, it's possible that this is working as designed.
--
Johan
Received on 2017-11-01 09:39:14 CET