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.s_at_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
Received on 2018-10-25 11:31:05 CEST