Re: Repository became corrupt on commit
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. 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 I note that your path had a /0/ after /revs/ but this appears to be empty. 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. Regards, Alan On Tue, Oct 23, 2018 at 3:54 PM Daniel Shahaf wrote: > > Daniel Shahaf wrote on Tue, 23 Oct 2018 14:50 +: > > Alan Spark wrote on Tue, 23 Oct 2018 14:41 +0100: > > > perl dump-noderev.pl /path/to/repository /trunk/scripts/script.py 728 > > > Use of uninitialized value $noderev_id in split at dump-noderev.pl line > > > 41. > > > > Sorry about that; the script is obviously missing an error check. > > > > Looks like 'svnlook' does not exist in your $PATH. > > > > It's not obvious to non Perl speakers, but line 6 does the > > equivalent of: > > . > > if [ -z "$SVNLOOK" ]; then SVNLOOK=svnlook ; fi > > . > > so if you run the script with svn/svnadmin/svnlook in PATH, _or_ with > > $SVN, $SVNADMIN, $SVNLOOK set to those executables' full paths, then it > > should work. > > The above is the preferred way forward, but if you hit roadblocks with > that, there _is_ a crude alternative: > > % grep -a '^type:' /path/to/repository/db/revs/0/728 > > This will extract only one field from the rfc822-formatted node-rev > header. It's a poor substitute to the Perl script, but better than nothing. > > Cheers, > > Daniel
Re: Repository became corrupt on commit
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
error
I got this error when I was updating my working copy: D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db_update_move.c' line 1039: assertion failed (move_dst_revision == expected_move_dst_revision || status == svn_wc__db_status_not_present) --- CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving..