Re: Repository became corrupt on commit

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.
The server has not been restarted. It is mod_dav_dvn. I'm not sure
what you mean by MPM, sorry.
---
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.
Use of uninitialized value $txn_id in pattern match (m//) at
dump-noderev.pl line 42.
Use of uninitialized value $txn_id in pattern match (m//) at
dump-noderev.pl line 43.
Use of uninitialized value $REVISION in division (/) at dump-noderev.pl line 10.
Use of uninitialized value $REVISION in modulus (%) at dump-noderev.pl line 11.
Use of uninitialized value $REVISION in concatenation (.) or string at
dump-noderev.pl line 13.
Use of uninitialized value $REVISION in concatenation (.) or string at
dump-noderev.pl line 15.
Use of uninitialized value $REVISION in concatenation (.) or string at
dump-noderev.pl line 16.
Use of uninitialized value $file_offset in concatenation (.) or string
at dump-noderev.pl line 49.
xxd: 1024: No such file or directory
Is there a simple command that I can run rather than this script?
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:
  core.c
  mod_so.c
  mod_watchdog.c
  http_core.c
  mod_log_config.c
  mod_logio.c
  mod_version.c
  mod_unixd.c
I'm not sure if that tells you anything but I don't think it is
prefork or worker.
Regards,
Alan
On Mon, Oct 22, 2018 at 4:54 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>
> Please send that to the list, not just to me. :)
>
> (To save a round trip: an MPM is an httpd thing, see https://httpd.apache.org/docs/current/mpm.html .  It's related to requests are distributed among httpd processes which factors in due to intra-process caches)
>
> Alan Spark wrote on Mon, 22 Oct 2018 16:50 +0100:
> > Hi Daniel,
> >
> > 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.
> >
> > The server has not been restarted. It is mod_dav_dvn. I'm not sure
> > what you mean by MPM, sorry.
> >
> > Regards,
> > Alan
> >
> > On Sat, Oct 20, 2018 at 6:04 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > >
> > > Alan Spark wrote on Fri, 19 Oct 2018 16:04 +0100:
> > > > * Error verifying revision 728.
> > > > svnadmin: E160013: Filesystem path 'trunk/scripts/script.py' is
> > > > neither a file nor a directory
> > >
> > > E160013 is SVN_ERR_FS_CORRUPT, but this message is a new one.
> > >
> > > Can you share the output of
> > > .
> > >     % dump-noderev.pl ${REPO_DIR} /trunk/scripts/script.py 728
> > > .
> > > 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".
> > >
> > > > The content of that file is what had replaced what used to be the trunk
> > > > folder. [...]  Now that we have deleted then re-committed exactly the same
> > > > file, the repository is back to normal and it seems like an unreproducable
> > > > bug at this stage.
> > >
> > > 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)?
> > >
> > > Cheers,
> > >
> > > Daniel
> > >
> > > [1] https://github.com/apache/infrastructure-puppet/blob/0a97d8e60798656d856bb0521bee76b24fbe5574/modules/rootbin_asf/files/bin/dump-noderev.pl