[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnadmin: Malformed representation header

From: Andrew n marshall <amarshal_at_ISI.EDU>
Date: 2006-08-29 07:21:44 CEST

As a clarification for those tracking the bug, it is indeed a FSFS
repository, despite my earlier comment otherwise.

Mark this as another case of issue 2467.


Andrew n marshall wrote:
> If I don't involve the directory containing the bad file, the
> repository seems to work fine. When trying to update a working copy
> with the bad file, TortoiseSVN gives:
> Error: REPORT request failed on
> '/svn/repos/REPOS_NAME/!svn/vcc/default' Error: REPORT of
> '/svn/repos/REPOS_NAME/!svn/vcc/default': 200 OK (http://HOSTNAME)
> (with actual REPOS_NAME and HOSTNAME, of course)
> I have a nightly backup. I cannot dump 7773, but I can dump
> everything after it in incremental mode.
> Apache logs don't say much:
> [Mon Aug 28 13:33:08 2006] [error] [client] A failure
> occurred while driving the update report editor [500, #160004]
> [Mon Aug 28 13:33:08 2006] [error] [client] Malformed
> representation header [500, #160004]
> Considering the size of the repository and current disk space issues,
> I'm looking for less drastic solutions than a rebuild. We don't have
> the room for a second repository on that machine, so we'd have to
> delete first. I'll test the backup files on another machine before
> I'm comfortable deleting anything.
> Anm
> Ivan Aleman wrote:
>> 2006/8/28, Andrew n marshall <amarshal@isi.edu>:
>>> I need some quick guidance. It seems my Berkeley DB backed repository
>>> became corrupted this morning. The error "svnadmin verify" gives is:
>>> * Verified revision 7772.
>>> svnadmin: Malformed representation header
>>> 340.849u 36.334s 13:58.04 45.0% 0+0k 0+0io 1pf+0w
>>> Revision 7773 happens to contain the last modification of the file that
>>> brought the problem to my attention. It is a large (multi-megabyte)
>>> binary media asset (the project is a game). And the committing user
>>> did
>>> not see any errors.
>>> I'm hosting the repository over a Fedora Core Linux box, Apache 2.0.54,
>>> and Subversion 1.2.3.
>>> Any guidance would be greatly appreciated. Is there a way to fix the
>>> file and database without tearing down the repository and rebuilding
>>> from backups?
>> Can you do a backup?
>> Can you work with the repository?
>> Have you any other information / error?
>> What about deleting the repository and then recreate it with some
>> one's working copy?
>> Please try to be more specific.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 07:26:11 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.