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 <nka...@gmail.com> wrote: > > On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf <danie...@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
