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