On Wed, Jul 31, 2013 at 10:44 AM, Philip Martin
> Daniel Shahaf <danielsh_at_elego.de> writes:
>> Jan (CC'd) reported an odd problem on IRC today: he would get
>> Corrupt representation '537009 564 9641 0 61d9000a8ccca3379173bbbbe0bb15bc' [500, #160004]
>> Malformed representation header at /swdev/ssd/CONVERSION/SVN/test/db/revs/537/537009:593
>> *sometimes* when he ran 'update --parents' that pulled in
>> a not-yet-in-the-wc file. The errors went away after he restarted
>> httpd. The error log had an EPERM on rev-prop-atomics.mutex which may
>> or may not be related.
>> Now, that error is actually very odd:
>> - "61d9000a8ccca3379173bbbbe0bb15bc" doesn't occur anywhere in the filesystem
>> (rep-cache.db and db/revs/**/*)
> Looking at the repository path ('CONVERSION' and 'test') and the fact
> that the error vanished when httpd was restarted is it possible this
> involved a temporary repository being replaced by another repository at
> the same path with the same UUID. If that happens I think apache may
> have been using the in-memory cache associated with the old repository
> when accessing the new repository.
I have been working with a user on a similar problem! Never would
have thought of the cache, but that makes sense. In my case they are
dumping and loading their repository to upgrade it to 1.8. As part of
this they rename the old and new at the end. After they do this
commits would fail with corrupt representation. Been pulling my hair
out wondering what it could be.
I have sent an email asking them to try stopping and starting Apache
after all this. Maybe it is as simple as that?
Received on 2013-07-31 17:00:26 CEST