You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@elego.de> on 2013/07/31 15:57:12 UTC
Unexplained "Corrupt representation" errors with 1.8.1
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/**/*)
- byte range [564, 564+9641] does not contain a start or end of a representation;
there is a representation
text: 537009 0 11118 3095593 e7f245ae8b4f219170fd5376e0fa4d02 c217337f689a3b2b7b87faf6267371af031d70a0 537008-bicw/_5
and I checked, it starts and ends in the right places (it is a DELTA
rep having a 20-byte header).
- Note that "593" is a byte offset, not a line number.
- The '0' either means "expanded size unknown", or --- if it means "the
expanded size is zero" --- then the md5 is wrong.
- The error message above is generated by representation_string(). The
filesystem is f6, so representation_string() should include the sha1
and uniquifier in its output; but it doesn't.
Environment:
- svn 1.8.1, wandisco package
- httpd-2.2.15-28.el6
- CentOS 6 64bit
- client and server run on the same machine
- fsfs.conf is empty
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Jul 31, 2013 at 3:57 PM, Daniel Shahaf <da...@elego.de> wrote:
> 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.
Even a corrupted FS may not always cause access failures
(depending on cache status, delta chains etc.). The default
strategy would be to run svnadmin verify.
> 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.
>
Well, the Apache / SVN user should get write access to the
repo folder. Otherwise, revprop caching won't work. But that
issue is not related to the corruption.
> Now, that error is actually very odd:
>
> - "61d9000a8ccca3379173bbbbe0bb15bc" doesn't occur anywhere in the
> filesystem
> (rep-cache.db and db/revs/**/*)
>
My first reaction as "cross-talk". Philip's explanation is probably
the most likely one.
> - byte range [564, 564+9641] does not contain a start or end of a
> representation;
> there is a representation
> text: 537009 0 11118 3095593 e7f245ae8b4f219170fd5376e0fa4d02
> c217337f689a3b2b7b87faf6267371af031d70a0 537008-bicw/_5
> and I checked, it starts and ends in the right places (it is a DELTA
> rep having a 20-byte header).
> - Note that "593" is a byte offset, not a line number.
> - The '0' either means "expanded size unknown", or --- if it means "the
> expanded size is zero" --- then the md5 is wrong.
>
0 means PLAIN representation in this case.
> - The error message above is generated by representation_string(). The
> filesystem is f6, so representation_string() should include the sha1
> and uniquifier in its output; but it doesn't.
>
Hashes (directories, properties) don't store a SHA1 for their
representation.
Since there is no fsfs.conf file, this repo does not use directory
deltification
which makes it likely that SVN is trying to access a directory
representation
(PLAIN, no SHA1).
>
> Environment:
>
> - svn 1.8.1, wandisco package
> - httpd-2.2.15-28.el6
> - CentOS 6 64bit
> - client and server run on the same machine
> - fsfs.conf is empty
>
-- Stefan^2.
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Ben Reser <be...@reser.org>.
On Wed, Jul 31, 2013 at 11:30 PM, Branko Čibej <br...@wandisco.com> wrote:
> People will also "svnadmin create" and then "cp -a" the results all over
> the place -- a case where using an inode is better than using a UUID.
At least with the cache system you can solve that by simply also
storing the path as part of your cache key.
E.G.
CACHE_KEY=$REPO_UUID:$INSTANCE_UUID:$PATH
If people move repos around with a running instance or even create and
then dup those repos the cache will still work properly. Though you
lose some efficiency if people move repos around without restarting
the server, but I think that's a small cost to pay since it's going to
be rare that people will be moving repos around without restarting the
server.
You can also add some code to the server to whine if you have multiple
repositories that it's caching with the same instance id. To try to
discourage people from doing this. On top of documentation to explain
why this is important.
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Branko Čibej <br...@wandisco.com>.
On 01.08.2013 07:32, Daniel Shahaf wrote:
> On Thu, Aug 01, 2013 at 07:04:15AM +0200, Branko Čibej wrote:
>> On 01.08.2013 05:38, Daniel Shahaf wrote:
>>> On Thu, Aug 01, 2013 at 05:31:56AM +0200, Branko Čibej wrote:
>>>> On 01.08.2013 04:17, Daniel Shahaf wrote:
>>>>> Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
>>>>>> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <be...@reser.org> wrote:
>>>>>>
>>>>>>> On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
>>>>>>> <ph...@wandisco.com> wrote:
>>>>>>>> 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.
>>>>>>> Realistically the UUID really shouldn't be used by caching to decide
>>>>>>> if it's looking at the same repo. Since it's exposed to clients users
>>>>>>> doing dump/load cycles are going to modify repos and end up with the
>>>>>>> same UUID. I'd suggest that we add another UUID that isn't exposed to
>>>>>>> the client and that svnadmin can't modify with load. The cache system
>>>>>>> should use this UUID for cache purposes.
>>>>>>>
>>>>>> +1. Let's call that UUID "instance ID".
>>>>> How about the inode number of the db/ directory?
>>>> Very portable, extremely cross-platform,
>>> apr_file_info.h
>>>
>>>> does not rely on details of filesystem design at all. :)
>>> When you design a filesystem that doesn't have a db/ directory at all, let me
>>> know.
>> Not to mention that inodes can be reused. Do you really want to design
>> that kind of Heisenbug?
> How do you propose to avoid it? If you just create a db/instance_uuid
> file, you'd have a heisenbug if people use 'zfs rollback' to restore
> a snapshot.
Yes, but at least it's something people actually have to /do/ instead of
just magically happening by itself. FWIW, your rollback example will
also break working copies, so that's not something I'd really worry
about solving.
People will also "svnadmin create" and then "cp -a" the results all over
the place -- a case where using an inode is better than using a UUID.
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Daniel Shahaf <da...@apache.org>.
On Thu, Aug 01, 2013 at 07:04:15AM +0200, Branko Čibej wrote:
> On 01.08.2013 05:38, Daniel Shahaf wrote:
> > On Thu, Aug 01, 2013 at 05:31:56AM +0200, Branko Čibej wrote:
> >> On 01.08.2013 04:17, Daniel Shahaf wrote:
> >>> Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
> >>>> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <be...@reser.org> wrote:
> >>>>
> >>>>> On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
> >>>>> <ph...@wandisco.com> wrote:
> >>>>>> 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.
> >>>>> Realistically the UUID really shouldn't be used by caching to decide
> >>>>> if it's looking at the same repo. Since it's exposed to clients users
> >>>>> doing dump/load cycles are going to modify repos and end up with the
> >>>>> same UUID. I'd suggest that we add another UUID that isn't exposed to
> >>>>> the client and that svnadmin can't modify with load. The cache system
> >>>>> should use this UUID for cache purposes.
> >>>>>
> >>>> +1. Let's call that UUID "instance ID".
> >>> How about the inode number of the db/ directory?
> >> Very portable, extremely cross-platform,
> > apr_file_info.h
> >
> >> does not rely on details of filesystem design at all. :)
> > When you design a filesystem that doesn't have a db/ directory at all, let me
> > know.
>
> Not to mention that inodes can be reused. Do you really want to design
> that kind of Heisenbug?
How do you propose to avoid it? If you just create a db/instance_uuid
file, you'd have a heisenbug if people use 'zfs rollback' to restore
a snapshot.
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Branko Čibej <br...@wandisco.com>.
On 01.08.2013 05:38, Daniel Shahaf wrote:
> On Thu, Aug 01, 2013 at 05:31:56AM +0200, Branko Čibej wrote:
>> On 01.08.2013 04:17, Daniel Shahaf wrote:
>>> Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
>>>> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <be...@reser.org> wrote:
>>>>
>>>>> On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
>>>>> <ph...@wandisco.com> wrote:
>>>>>> 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.
>>>>> Realistically the UUID really shouldn't be used by caching to decide
>>>>> if it's looking at the same repo. Since it's exposed to clients users
>>>>> doing dump/load cycles are going to modify repos and end up with the
>>>>> same UUID. I'd suggest that we add another UUID that isn't exposed to
>>>>> the client and that svnadmin can't modify with load. The cache system
>>>>> should use this UUID for cache purposes.
>>>>>
>>>> +1. Let's call that UUID "instance ID".
>>> How about the inode number of the db/ directory?
>> Very portable, extremely cross-platform,
> apr_file_info.h
>
>> does not rely on details of filesystem design at all. :)
> When you design a filesystem that doesn't have a db/ directory at all, let me
> know.
I was talking about file systems, not Subversion's versioned filesystem
backend. If you look closely at the APR implementation, you'll find that
the "inode number" is not guaranteed to be persistent on Windows. It all
depends on which file system you happen to be using.
Not to mention that inodes can be reused. Do you really want to design
that kind of Heisenbug?
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Daniel Shahaf <da...@apache.org>.
On Thu, Aug 01, 2013 at 05:31:56AM +0200, Branko Čibej wrote:
> On 01.08.2013 04:17, Daniel Shahaf wrote:
> > Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
> >> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <be...@reser.org> wrote:
> >>
> >>> On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
> >>> <ph...@wandisco.com> wrote:
> >>>> 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.
> >>> Realistically the UUID really shouldn't be used by caching to decide
> >>> if it's looking at the same repo. Since it's exposed to clients users
> >>> doing dump/load cycles are going to modify repos and end up with the
> >>> same UUID. I'd suggest that we add another UUID that isn't exposed to
> >>> the client and that svnadmin can't modify with load. The cache system
> >>> should use this UUID for cache purposes.
> >>>
> >> +1. Let's call that UUID "instance ID".
> > How about the inode number of the db/ directory?
>
> Very portable, extremely cross-platform,
apr_file_info.h
> does not rely on details of filesystem design at all. :)
When you design a filesystem that doesn't have a db/ directory at all, let me
know.
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Branko Čibej <br...@wandisco.com>.
On 01.08.2013 04:17, Daniel Shahaf wrote:
> Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
>> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <be...@reser.org> wrote:
>>
>>> On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
>>> <ph...@wandisco.com> wrote:
>>>> 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.
>>> Realistically the UUID really shouldn't be used by caching to decide
>>> if it's looking at the same repo. Since it's exposed to clients users
>>> doing dump/load cycles are going to modify repos and end up with the
>>> same UUID. I'd suggest that we add another UUID that isn't exposed to
>>> the client and that svnadmin can't modify with load. The cache system
>>> should use this UUID for cache purposes.
>>>
>> +1. Let's call that UUID "instance ID".
> How about the inode number of the db/ directory?
Very portable, extremely cross-platform, does not rely on details of
filesystem design at all. :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Daniel Shahaf <da...@elego.de>.
Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <be...@reser.org> wrote:
>
> > On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
> > <ph...@wandisco.com> wrote:
> > > 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.
> >
> > Realistically the UUID really shouldn't be used by caching to decide
> > if it's looking at the same repo. Since it's exposed to clients users
> > doing dump/load cycles are going to modify repos and end up with the
> > same UUID. I'd suggest that we add another UUID that isn't exposed to
> > the client and that svnadmin can't modify with load. The cache system
> > should use this UUID for cache purposes.
> >
>
> +1. Let's call that UUID "instance ID".
How about the inode number of the db/ directory?
The issue of "instance UUID" already came up in the context of svnsync
write-through proxy mirrors, to distinguish the slave from the master.
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <be...@reser.org> wrote:
> On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
> <ph...@wandisco.com> wrote:
> > 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.
>
> Realistically the UUID really shouldn't be used by caching to decide
> if it's looking at the same repo. Since it's exposed to clients users
> doing dump/load cycles are going to modify repos and end up with the
> same UUID. I'd suggest that we add another UUID that isn't exposed to
> the client and that svnadmin can't modify with load. The cache system
> should use this UUID for cache purposes.
>
+1. Let's call that UUID "instance ID".
-- Stefan^2.
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Ben Reser <be...@reser.org>.
On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
<ph...@wandisco.com> wrote:
> 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.
Realistically the UUID really shouldn't be used by caching to decide
if it's looking at the same repo. Since it's exposed to clients users
doing dump/load cycles are going to modify repos and end up with the
same UUID. I'd suggest that we add another UUID that isn't exposed to
the client and that svnadmin can't modify with load. The cache system
should use this UUID for cache purposes.
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
> I have sent an email asking them to try stopping and starting Apache
> after all this. Maybe it is as simple as that?
It definitely happens. I don't know whether it applies to the problem
reported by Daniel.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jul 31, 2013 at 10:44 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Daniel Shahaf <da...@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?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Daniel Shahaf <da...@elego.de>.
Daniel Shahaf wrote on Wed, Jul 31, 2013 at 18:24:49 +0300:
> Philip Martin wrote on Wed, Jul 31, 2013 at 15:44:47 +0100:
> > Daniel Shahaf <da...@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.
>
> You're right about the "same path and uuid" point (see
> svn_fs_fs__initialize_caches()).
>
> That said, I tried to reproduce it by:
>
> % ./davautocheck.sh --no-tests
> % ./basic_tests.py --url=http://localhost:3691 3
> % cd svn-test-work/repositories/
> % $svnadmin hotcopy basic_tests-3 c
> % $s import -q -mm =(echo before) $u/basic_tests-3/foo
> % $s cat $u/basic_tests-3/foo
> before
> % mv basic_tests-3 before
> % mv c basic_tests-3
> % $s import -q -mm =(echo after) $u/basic_tests-3/foo
> % $s cat $u/basic_tests-3/foo
> after
>
> and I got the right answer. Since I had "SVNCacheFullTexts On" in the
> config, I had expected the last 'cat' to return "before\n". Why didn't
> it return "before\n"?
Never mind. It reproduces when I run the first "cat" multiple times.
Probably because I use a forking MPM.
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Daniel Shahaf <da...@elego.de>.
Philip Martin wrote on Wed, Jul 31, 2013 at 15:44:47 +0100:
> Daniel Shahaf <da...@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.
You're right about the "same path and uuid" point (see
svn_fs_fs__initialize_caches()).
That said, I tried to reproduce it by:
% ./davautocheck.sh --no-tests
% ./basic_tests.py --url=http://localhost:3691 3
% cd svn-test-work/repositories/
% $svnadmin hotcopy basic_tests-3 c
% $s import -q -mm =(echo before) $u/basic_tests-3/foo
% $s cat $u/basic_tests-3/foo
before
% mv basic_tests-3 before
% mv c basic_tests-3
% $s import -q -mm =(echo after) $u/basic_tests-3/foo
% $s cat $u/basic_tests-3/foo
after
and I got the right answer. Since I had "SVNCacheFullTexts On" in the
config, I had expected the last 'cat' to return "before\n". Why didn't
it return "before\n"?
Re: Unexplained "Corrupt representation" errors with 1.8.1
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <da...@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.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data