Re: Repository became corrupt on commit

2018-10-24 Thread Alan Spark
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

2018-10-24 Thread Daniel Shahaf
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

2018-10-24 Thread Keith.Wentworth
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..