Hi Daniel, > Odd. My first assumption is that the subshell on line 39 isn't behaving > as expected. If you run `svnlook tree --full-paths --show-ids -r 719 > /path/to/repository /trunk/scripts/script.py`, does print a path and a > node-rev id string (which looks like "a.b.c/d-e")?
Here is the output that I got: svnlook tree --full-paths --show-ids -r 719 /path/to/repository /trunk/scripts/script.py svnlook: E160016: Failure opening '/trunk/scripts/script.py' svnlook: E160016: '/trunk' is not a directory in filesystem '6b6eeb5b-1909-4e6c-8b33-d77c8e70ace5' If I run this on 718 then I get this output: svnlook tree --full-paths --show-ids -r 718 /path/to/repository /trunk/scripts/script.py /trunk/scripts/script.py <3.0.r716/391789> > These all look correct. I assume that when you do a normal 'verify' > run, revisions 1:718 (inclusive) are verified successfully and 719 > errors out, correct? I.e., it prints "Verifying revision 718" and then > "Error verifying revision 719". That is correct: * Verified revision 718. * Error verifying revision 719. svnadmin: E160013: Filesystem path 'trunk/doc/EDITS.txt' is neither a file nor a directory > There's a slim chance that those "type:" lines had a NUL byte tacked on, > or something else that got lost in the translation to email. You can > rule out this remote possibility by piping the grep to xxd(1) (just > '| xxd', no option flags needed). Here is 718: grep -a '^type:' /path/to/repository/db/revs/718 | xxd 00000000: 7479 7065 3a20 6669 6c65 0a74 7970 653a type: file.type: 00000010: 2064 6972 0a74 7970 653a 2064 6972 0a74 dir.type: dir.t 00000020: 7970 653a 2064 6972 0a74 7970 653a 2064 ype: dir.type: d 00000030: 6972 0a74 7970 653a 2064 6972 0a ir.type: dir. And 719: grep -a '^type:' /path/to/repository/db/revs/719 | xxd 00000000: 7479 7065 3a20 6669 6c65 0a74 7970 653a type: file.type: 00000010: 2064 6972 0a > Otherwise, could you please confirm that the error you're getting on > r719 is the same one you posted for r728 (except for the revision > number, of course)? Yes, although I just noticed that it is a different file in this case but same error code: * Verified revision 718. * Error verifying revision 719. svnadmin: E160013: Filesystem path 'trunk/doc/EDITS.txt' is neither a file nor a directory I re-ran the svnlook commands on this file and get the same results: svnlook tree --full-paths --show-ids -r 719 /path/to/repository /trunk/doc/EDITS.txt svnlook: E160016: Failure opening '/trunk/doc/EDITS.txt' svnlook: E160016: '/trunk' is not a directory in filesystem '6b6eeb5b-1909-4e6c-8b33-d77c8e70ace5' And on 718: svnlook tree --full-paths --show-ids -r 718 /path/to/repository /trunk/doc/EDITS.txt /trunk/doc/EDITS.txt <166.0.r717/510746> Regards, Alan On Wed, Oct 24, 2018 at 3:08 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Alan Spark wrote on Wed, 24 Oct 2018 08:57 +0100: > > Hi Daniel, > > > > I didn't get anywhere with the perl script. /usr/bin is definitely in > > the path and that is where svnlook is, and the SVNLOOK variable was > > already set... anyway I gave up and went for your alternative. > > > > Odd. My first assumption is that the subshell on line 39 isn't behaving > as expected. If you run `svnlook tree --full-paths --show-ids -r 719 > /path/to/repository /trunk/scripts/script.py`, does print a path and a > node-rev id string (which looks like "a.b.c/d-e")? > > > Firstly I must apologise as I stated revision 728 in my original email > > but it looks like this was on one of our experimental copies of the > > repository that we no longer have. I do still have a copy of the > > broken repository at revision 719. With that in mind, I ran this: > > > > grep -a '^type:' /path/to/repository/db/revs/719 > > type: file > > type: dir > > > > I also ran on the last working revision: > > > > grep -a '^type:' /path/to/repository/db/revs/718 > > type: file > > type: dir > > type: dir > > type: dir > > type: dir > > type: dir > > > > These all look correct. I assume that when you do a normal 'verify' > run, revisions 1:718 (inclusive) are verified successfully and 719 > errors out, correct? I.e., it prints "Verifying revision 718" and then > "Error verifying revision 719". > > There's a slim chance that those "type:" lines had a NUL byte tacked on, > or something else that got lost in the translation to email. You can > rule out this remote possibility by piping the grep to xxd(1) (just > '| xxd', no option flags needed). > > Otherwise, could you please confirm that the error you're getting on > r719 is the same one you posted for r728 (except for the revision > number, of course)? > > > I note that your path had a /0/ after /revs/ but this appears to be empty. > > > > It's normal for that path not to exist, particularly in older repositories. > It > shouldn't exist empty, but that's harmless. > > > I think I have confirmed that our MPM is prefork: > > > > a2query -M > > prefork > > > > I hope this helps. Let me know if you need me to check anything else. > > Yes, it does. > > Thanks, > > Daniel
