Alan Spark wrote on Tue, 23 Oct 2018 14:41 +0100:
> Hi Daniel,
>
> Sorry, I meant to reply to all. For the benefit of others, here is what I said:
>
> ---
> Thanks for the response.
>
> > where dump-noderev.pl is [1]? The output should be just a few rfc822-like
> > headers specifying the offset and checksum of the file contents representation
> > ("rep"). One of the headers should be "type: file".
>
> I'll take a look at this as soon as I can.
>
> > Sorry, I don't follow. Can you explain again what the contents of the
> > file is and what's its significance? Has the server been restarted
> > between the two commit attempts? Is it svnserve (in which mode,
> > -i/-t/-d/-T/service) or mod_dav_svn (which MPM)?
>
> The file is a python script. It is just a text file. The first time it
> was committed it corrupted the repository. We rolled back to a backup
> and tried to commit the same file and it again broke the repository.
> Only when we deleted, then added exactly the same file did the problem
> go away. So it was reproducible until we rolled back and deleted the
> file.
>
Thanks, this is important information.
> I'm afraid I'm new to perl so I may be doing something wrong, but I
> checked out the entire infrastructure-puppet repository and ran the
> command from within
> ~/infrastructure-puppet/modules/rootbin_asf/files/bin to get the
> following output:
>
> 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.
> Is there a simple command that I can run rather than this script?
>
Not really. The script dumps an internal data structure (a node-rev is
basically an inode in Subversion's versioned filesystem) and is the easiest way
to do that. We could probably instrument the C code instead but (a) I don't have
that patch ready, (b) you'd then have to rebuild svn.
> I tried to find out what our MPM is but I am not sure. I ran this command:
>
> /usr/sbin/apache2 -l
> Compiled in modules:
>
> I'm not sure if that tells you anything but I don't think it is
> prefork or worker.
It doesn't, I'm afraid. It looks like you're using a *.so MPM but
that's not proof of _which_ MPM it is.
I'm asking about MPM because that ties to svn's internal caches. (If
you used prefork, the bug's happening twice would rule out intra-process
caches as a cause.)
Cheers,
Daniel
Received on 2018-10-23 16:50:38 CEST