You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Sergey Proskurnya <al...@gmail.com> on 2006/05/19 07:24:06 UTC

svnadmin: Can't read length line in file ...

Hi,

I have discovered that my repository is broken.
Performing "svnadmin dump", I got the following error:
svnadmin: Can't read length line in file '/path/to/MyRepo/db/revs/1714'

"svn up/co" also fails with the following error:
"svn: Malformed representation header" while checkouting files
in problem revision(1714).

Subversion server and client versions: 1.2.3
Subversion server backend: FSFS
OS: GNU Linux 2.6.x kernel
Access via HTTPS (Apache 2.0.x + NEON 0.24.7).


I've searched through Google, not nothing useful was found.
Any ideas?

Thanks,
Serge.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svnadmin: Can't read length line in file ...

Posted by Sergey Proskurnya <al...@gmail.com>.
Mark Junker schrieb:
> Sergey Proskurnya schrieb:
> 
>> I have discovered that my repository is broken.
>> Performing "svnadmin dump", I got the following error:
>> svnadmin: Can't read length line in file '/path/to/MyRepo/db/revs/1714'
> 
> I had the same problem. When revision 1714 is the last in your
> repository, you should try "svnadmin recover". When it cannot fix your
> repository, you have to go the hard way. The only solution for me was to
> "fix" the revision by executing the following steps:
> 
> 1. Dump everything up to the damaged revision-1 (dump 1)
> 2. Dump everything from damaged revision+1 to HEAD (with --incremental)
> (dump 2)
> 3. Load "dump 1" into a new repository
> 4. Do a check-out
> 5. Re-Commit the changes for the damaged revision
> 6. Load "dump 2" into the new repository
> 
> Now everything should work again. The biggest problem is to commit only
> the changes done in the damaged revision. I had luck because I was able
> to reconstruct it easily.

Thanks for comprehensive answer!
I was too stupid to use --incremental switch,
so I was unable to dump revs after broken one.
By the way, I have found 4 (!) broken revs in the repo.

>> OS: GNU Linux 2.6.x kernel
> Our server is running SuSE Linux 9.3 x86_64.
No, we are using Lunar-Linux (x86)

> 
> I had the same problem but nobody answered ... so I guess this problem
> is very rare. BTW: At this time we were running "svnserve" (svn://) and
> "mod_dav_svn" (https://) at the same time. Maybe this could've been the
> problem? Now we're only using the https:// access method.
We don't use file:// or svn:// access methods at all. Only HTTPS.
So, most probably this problem was not caused by accessing repo in
different methods.

I start to think about BDB backend again.
At least it has working "svnadmin recover" ;-))

Many thanks,
Serge.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svnadmin: Can't read length line in file ...

Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Friday 19 May 2006 09:36, Mark Junker wrote:
> 1. Dump everything up to the damaged revision-1 (dump 1)
> 2. Dump everything from damaged revision+1 to HEAD (with --incremental)
> (dump 2)
> 3. Load "dump 1" into a new repository
> 4. Do a check-out
> 5. Re-Commit the changes for the damaged revision
> 6. Load "dump 2" into the new repository


I have an easier variant:
1. Load everything from rev0 to revN from the last backup (which is valid, 
right?).
2. Use --incremental to dump the missing revisions between revN and HEAD from 
the live repository and load them, too.
3. Only if any revisions in the range revN and HEAD are damaged beyond repair 
you will have to manually fix those revisions using above checkout/edit 
means.

Uli

****************************************************
Visit our website at <http://www.domino-printing.com/>
****************************************************
This Email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this Email in error please notify the system manager.

This footnote also confirms that this Email message has been swept by MailSweeper for the presence of computer viruses.
****************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svnadmin: Can't read length line in file ...

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 5/22/06, Sergey Proskurnya <al...@gmail.com> wrote:
> Ryan Schmidt wrote:
>
> > behind it. I haven't been following this thread so I don't know how much
> > or if any of the Subversion developers have chimed in, but usually if
> > there's a corrupt FSFS repository they'll ask to see it or part of it
> > or, if it's got sensitive data, work with you to analyze it remotely to
> > figure out what went wrong.
>
> I have an original broken revs and can share them with developers.

Was the commit that created the revision in question really large?
Like multiple gigabytes in size?

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svnadmin: Can't read length line in file ...

Posted by Sergey Proskurnya <al...@gmail.com>.
Ryan Schmidt wrote:

> behind it. I haven't been following this thread so I don't know how much
> or if any of the Subversion developers have chimed in, but usually if
> there's a corrupt FSFS repository they'll ask to see it or part of it
> or, if it's got sensitive data, work with you to analyze it remotely to
> figure out what went wrong.

I have an original broken revs and can share them with developers.

Regards,
Serge.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svnadmin: Can't read length line in file ...

Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 22, 2006, at 08:40, Mark Junker wrote:

>> I'd love to know what causes this...  This is a pretty serious  
>> issue IMHO.
>> I'm going to try to reproduce the scenario after I fix our  
>> repository, but
>> I'm not hopeful about succeeding.
>
> I also think that this is a serious issue but the only thing we  
> have in common is the FSFS repository. Maybe I should convert it to  
> BDB?

I wouldn't recommend that, because I've been recommending that people  
switch from BDB to FSFS for a year. Not only do I not want to look  
foolish :-) but there are very real problems with the way Subversion  
uses BDB which cause it to blow up in some environments, about which  
you can certainly read more in the mailing list archives. If there's  
a problem with FSFS, then let's find it and fix it. FSFS is the  
default repository type now which means the Subversion team has put  
its weight behind it. I haven't been following this thread so I don't  
know how much or if any of the Subversion developers have chimed in,  
but usually if there's a corrupt FSFS repository they'll ask to see  
it or part of it or, if it's got sensitive data, work with you to  
analyze it remotely to figure out what went wrong.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svnadmin: Can't read length line in file ...

Posted by Mark Junker <m....@hm-software.de>.
Andrew MacKenzie schrieb:
>>> I've searched through Google, not nothing useful was found.
>>> Any ideas?

>> I had the same problem but nobody answered ... so I guess this problem 
>> is very rare. BTW: At this time we were running "svnserve" (svn://) and 
>> "mod_dav_svn" (https://) at the same time. Maybe this could've been the 
>> problem? Now we're only using the https:// access method.

> We're only using mod_dav_svn.

So I guess that it's not a problem of using svnserve and mod_dav_svn 
together.

> It seemed to only effect one file in the revision that 'went bad'.  That
> file was a binary file (.mdb) with the 'svn:needs-lock' property set.  The
> person who commited the revision thinks she didn't lock the file before
> commiting it (just changed the read-only flag).  

Hmm ... we don't use the "svn:needs-lock" attribute here so I guess that 
this isn't the problem.

> I'd love to know what causes this...  This is a pretty serious issue IMHO.
> I'm going to try to reproduce the scenario after I fix our repository, but
> I'm not hopeful about succeeding.

I also think that this is a serious issue but the only thing we have in 
common is the FSFS repository. Maybe I should convert it to BDB?

-- 
Kind regards,
Mark Junker
HM-Software

Re: svnadmin: Can't read length line in file ...

Posted by Andrew MacKenzie <am...@edespot.com>.
> >I have discovered that my repository is broken.
> >Performing "svnadmin dump", I got the following error:
> >svnadmin: Can't read length line in file '/path/to/MyRepo/db/revs/1714'
> I had the same problem. When revision 1714 is the last in your 
> repository, you should try "svnadmin recover". When it cannot fix your 
> repository, you have to go the hard way. The only solution for me was to 
> "fix" the revision by executing the following steps:
I've just run into this issue as well...

> >Subversion server and client versions: 1.2.3
> I used SVN HEAD
We're running 1.3.1.

> >Subversion server backend: FSFS
> Hmm ... I used FSFS too
Same here.

> >OS: GNU Linux 2.6.x kernel
> Our server is running SuSE Linux 9.3 x86_64.
Our server is Win2k3.

> >Access via HTTPS (Apache 2.0.x + NEON 0.24.7).
> We use Apache 2.2.0 + NEON 0.24.7
We're using Apache 2.0.58.  Not sure what version of NEON.

> >I've searched through Google, not nothing useful was found.
> >Any ideas?
> I had the same problem but nobody answered ... so I guess this problem 
> is very rare. BTW: At this time we were running "svnserve" (svn://) and 
> "mod_dav_svn" (https://) at the same time. Maybe this could've been the 
> problem? Now we're only using the https:// access method.
We're only using mod_dav_svn.

Other information about our issue:

It seemed to only effect one file in the revision that 'went bad'.  That
file was a binary file (.mdb) with the 'svn:needs-lock' property set.  The
person who commited the revision thinks she didn't lock the file before
commiting it (just changed the read-only flag).  

I'd love to know what causes this...  This is a pretty serious issue IMHO.
I'm going to try to reproduce the scenario after I fix our repository, but
I'm not hopeful about succeeding.

I'm willing to test some scenarios using the old repository and with it as
it was 'just before it went bad' if somebody has any suggestions.

-- 
// Andrew MacKenzie  |  http://www.edespot.com
// GPG public key: http://www.edespot.com/~amackenz/public.key
// "If my theory of relativity is proven successful, Germany will claim
//  me as a German and France will declare that I am a citizen of the
//  world. Should my theory prove untrue, France will say that I am a
//  German and Germany will declare that I am a Jew."
//     -- Albert Einstein

Re: svnadmin: Can't read length line in file ...

Posted by Mark Junker <m....@hm-software.de>.
Sergey Proskurnya schrieb:

> I have discovered that my repository is broken.
> Performing "svnadmin dump", I got the following error:
> svnadmin: Can't read length line in file '/path/to/MyRepo/db/revs/1714'

I had the same problem. When revision 1714 is the last in your 
repository, you should try "svnadmin recover". When it cannot fix your 
repository, you have to go the hard way. The only solution for me was to 
"fix" the revision by executing the following steps:

1. Dump everything up to the damaged revision-1 (dump 1)
2. Dump everything from damaged revision+1 to HEAD (with --incremental) 
(dump 2)
3. Load "dump 1" into a new repository
4. Do a check-out
5. Re-Commit the changes for the damaged revision
6. Load "dump 2" into the new repository

Now everything should work again. The biggest problem is to commit only 
the changes done in the damaged revision. I had luck because I was able 
to reconstruct it easily.

> Subversion server and client versions: 1.2.3

I used SVN HEAD

> Subversion server backend: FSFS

Hmm ... I used FSFS too

> OS: GNU Linux 2.6.x kernel

Our server is running SuSE Linux 9.3 x86_64.

> Access via HTTPS (Apache 2.0.x + NEON 0.24.7).

We use Apache 2.2.0 + NEON 0.24.7

> I've searched through Google, not nothing useful was found.
> Any ideas?

I had the same problem but nobody answered ... so I guess this problem 
is very rare. BTW: At this time we were running "svnserve" (svn://) and 
"mod_dav_svn" (https://) at the same time. Maybe this could've been the 
problem? Now we're only using the https:// access method.

-- 
Regards,
Mark Junker
HM-Software