2010/3/3 Mariusz Droździel :
> Well, actually at first this one seemed to be quite trivial. Its
> enough to raise Apache loglevel to debug in order to see the exact
> filenames in mod_authnz_ldap logs.
Ok, in the end the solution described by Martin worked great. Thanks
big time! Small tip for an
2010/3/3 Mariusz Droździel :
> I am forwarding the original post below, in case someone else will
> encounter similar problem. In my case the issue is, that I have no
> idea which files are broken. While doing sync or checkout I just get
> the following error in logs:
Well, actually at first this
2010/3/3 Kutter, Martin :
I am forwarding the original post below, in case someone else will
encounter similar problem. In my case the issue is, that I have no
idea which files are broken. While doing sync or checkout I just get
the following error in logs:
[Wed Mar 03 11:07:53 2010] [error] [cli
2010/3/2 Kutter, Martin :
> This sounds a bit like our issue discussed in thread
> "Corrupted FSFS commit" just a few days ago on this list.
> We managed to create a copy of the repository without the corrupted
> files using path-based authorization and svnsync.
Could you give me some more insigh
> Mariusz Droździel wrote:
> After some time it turned out, that there are few revisions in our
> repository, which are broken, probably on the filesystem level.
>
> % svnadmin verify /storage/svn
> [...]
> * Verified revision 1025.
> * Verified revision 1026.
> svnadmin: Decompression of svndiff
Hello,
After some time it turned out, that there are few revisions in our
repository, which are broken, probably on the filesystem level.
Unfortunetely as time went by, backups we made contain only those
broken revisions so we have no chance in getting stuph working just by
simple recovery. Only h
