Jason Wong wrote on Wed, Feb 15, 2012 at 10:20:23 -0800:
> On Wed, Feb 8, 2012 at 6:22 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> > On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> >> Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
> >>> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
> >
> >>> Get xxd.exe from http://www.vim.org/ and cat.exe and sed.exe from
> >>> http://gnuwin32.sf.net (or from Cygwin). Delete from the script the
> >>> line that uses the 'head' command.
> >>
> >> There is a second use of 'head', which you shouldn't delete. So
> >> instead, just get head.exe from the same place as the other two, or use
> >> the following kind of statement:
> >
> > Or install CygWin and run the scripts from inside CygWin. This does
> > present end-of-line issues, so be very careful about using "svn:eol
> > native" properties.
> >
> >>
> >> my $line = do {
> >> open FOO, "perl -V 2>&1 |";
> >> <FOO>;
> >> };
> >>
> >> Lastly, there's a 'sed' invocation that uses single-quoted arguments.
> >> All it does is "print the input up to the first empty line" --- feel
> >> free to implement it differently. (One way:
> >>
> >> my @lines = split /\n/, `command | goes | here`;
> >> $_ and print or last for @lines;
> >>
> >> Both of these examples could do with some error checking.)
> >>
> >> Daniel
> >> (yes, there's also a neater way to do this without split(). but it's
> >> not a Perl class here)
>
> Hello.
>
> Sorry for the delay. Here is an update of what I have done since
> the last time I posted.
>
> I have run "svn log -q ^/" on the respository and it came back with
> no missing revisions.
>
I stand corrected, then. I've confirmed on another instance of the bug
that 'svn log -q ^/' does not behave abnormally when the bug is present.
Sorry for the misinformation.
Question to devs: what operation will walk the predecessor links for
the root fspath? (and can therefore be used to identify instances of
the bug)
> Since I first posted, each of the projects we have tried to build
> that had failed have since successfully been built without any changes
> on our side.
>
What is the significance of this? I don't know how your build process
interacts with Subversion.
> I was having an issue with converting the script to run in windows as
> I was only getting the first line returned so I set up cygwin.
>
> I ran the script against both of the revisions (61815 and 61852) in
> mentioned in the Apache error log and the output was the same for
> each.
>
> Commands:
> dump-noderev.pl /repository
> /project/binaries/release/phase1/iteration/81/trunk 61815
> dump-noderev.pl /repository
> /project/binaries/release/phase1/iteration/81/trunk 61852
>
> Output:
> id: 9-45362.0-61242.r61424/0
> type: dir
> pred: 9-45362.0-60310/0
Are you sure that's the value of the pred: field? It contains only
one ".", instead of two.
> count: 43
> text: 58741 121716266 218 218 74eb31e90880ba1345fc49252ca6efe6
> cpath: /project/binaries/release/phase1/iteration/81/trunk
> copyfrom: 61423 /project/binaries/release/phase1/iteration/80/trunk
>
> Is this information helpful? Let me know if this tells you anything. Thanks
>
The fact that the output is identical suggests that the
/project/binaries/release/phase1/iteration/81/trunk tree hasn't changed
between those two revisions (or that there was a directory replace above
it).
However, this is the error you report:
[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]
The metadata this error complains about will be output by these two
commands:
./dump-noderev.pl /repository / 61851
./dump-noderev.pl /repository / 61852
> Jason.
Cheers,
Daniel
Received on 2012-02-16 03:16:18 CET