Re: predecessor count for the root node-revision is wrong message

Jason Wong wrote on Tue, Feb 07, 2012 at 13:23:10 -0800:
> Hello.
>
> I have recently run into an issue with my subversion system (1.7.1)
> where a specific component I am trying to build has failed. I have
> had sucessful builds of this project before this issue happened since
> we upgraded to 1.7.1. I am currently getting by this by using
> TortoiseSVN 1.7.1 to do the check-in of the files left in the
> workspace.
>
> This issue seems to be intermittent as it does not happen every time.
> I am using subversion 1.7.1 windows binaries and subversion is
> hosting on Apache 2.2.21.
>
> I have run "svnadmin verify" against the directory and it has come
> back clean. I was wondering what type of events can cause this to
> happen? Are there any resolutions?
>
> Here are some entries from the apache log for the last time this
> issue happened.
>
> The Apache error log shows the following lines:
>
>     [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] Could not
> MERGE resource "/repository/!svn/txn/61847-1bz5" into
> "/repository/project/binaries/release/phase1/iteration/81/trunk
> ". [409, #0]
>     [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] An error
> occurred while committing the transaction.  [409, #160004]
>     [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] predecessor
> count for the root node-revision is wrong: found 61815,
> committing r61852  [409, #160004]

This error message indicates a bug has been detected. The implications
of the bug are that walking backwards through history (eg, 'svn log -r
HEAD:0') may skip some revisions.

I'm interested in getting to the bottom of this.

There are two ways to identify instances of the bug: either by directly
querying the filesystem (explained below), or by running 'svn log -q ^/'
and looking for gaps in the sequences of revision numbers.

The second approch is as follows: look for revisions N such that
f(N) != f(N-1), where f(N) is 'N minus (predecessors count of the
node-revision of / in revision N)'. To compute f(), you find the
predecessors count; it is given by the 'count:' header in the output
of the attached script:

  % ./dump-noderev.pl /tmp/svn/r1 / 1
  id: 0.0.r1/4760
  type: dir
  pred: 0.0.r0/17
  count: 1
  text: 1 4640 107 107 c34b7d0de08f48db97941642f719e2f4
  cpath: /
  copyroot: 0 /

So, in summary, there are two ways to identify revisions that trigger
the bug: by 'svn log' or by manually looking for gaps in the sequence of
node-revisions of the root of the filesystem.

I would ask you to run the attached script anyway, on the HEAD revision,
and review its output for sensibility --- in particular, what is the
value of the minfo-cnt header (if present).

>     [Tue Jan 31 11:37:24 2012] [error] [client 9.31.13.109] Could not
> fetch resource information.  [404, #0]
>     [Tue Jan 31 11:37:24 2012] [error] [client 9.31.13.109] Named
> transaction doesn't exist.  [404, #0]
>
> The following are from the Apache access log at the same time:
>
>     9.31.13.109 - username [31/Jan/2012:11:37:22 -0800] "MERGE
> /repository/project/binaries/release/phase1/iteration/81/trunk
> HTTP/1.1" 409 281
>     9.31.13.109 - username [31/Jan/2012:11:37:24 -0800] "DELETE
> /repository/!svn/txn/61847-1bz5 HTTP/1.1" 404 232
>
> Any help/comments would be appreciated. Thank you.
>

As I said, I'd be interested in isolating the cause of these errors.
Is there anything common to revisions that triggered the bug (as
explained above)? Are they concomitant with concurrent writes (commits,
propedits, 'svn lock' operations, 'svnadmin pack' operations)? What
version of svn does your server run (1.7.1?)? What operating system
does your server run? Is there anything noteworthy about its
filesystems or disks?

>
> Jason Wong

Thanks,

Daniel