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

Re: modify-file within an added tree (r1356317) ; possibly rep-cache.db -related

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 10 Jul 2012 10:04:49 +0100

Trent Nelson <trent_at_snakebite.org> writes:

> On 7/8/12 11:48 AM, "Daniel Shahaf" <d.s_at_daniel.shahaf.name> wrote:
>
>>Daniel Shahaf wrote on Sat, Jul 07, 2012 at 15:09:38 +0100:
>>> How can we have a 'modify-file' within an added-without-copyfrom tree?
>
> That's a pretty impressive invariant violation. Enversion would have
> caught it, but only because we assert that a modify's previous path must
> match its current path -- not because we specifically look for this
> situation.

"svnadmin verify" detects the problem because the path does not exist in
the previous revision:

svnadmin: E160013: File not found: revision 1356316, path
'/lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler/loader/package-summary.html

That is really just a side-effect of another check; it's not a reliable
way to detect this sort of corruption since it could be defeated if the
modify-file occurred within a replace-without-copyfrom, rather than an
add-without-copyfrom, and the path existed in the replaced tree.

> I've also never come across this in the wild. We should definitely ping
> `rmuir` to find out how he committed that revision; platform, version, etc.

The operation log on people.a.o has:

[02/Jul/2012:16:11:33 +0000] xx.xx.xx.xx rmuir commit r1356317 790 -

The access log has:

svn.apache.org xx.xx.xx.xx - rmuir [02/Jul/2012:16:11:33 +0000] "MERGE /repos/
asf/lucene/cms/trunk/content/solr HTTP/1.1" 200 49122 "-" "SVN/1.7.2 neon/0.29.6
" - 443

It's a v2 protocol commit.

These lines are timestamped 16:11:33 but the surrounding lines are
timestamped 16:24:43 so there was a 13min server-side post-commit
period. Perhaps the SQLite rep-cache update?

>>>Isn't svnsync correct to complain in this case?
>
> Definitely.
>
>>I'd like to resolve the situation on the live svn.a.o repository. I see
>>a couple of ways to do so:
>>
>>- Hand-edit the revision file, changing "modify-file" to "add-file "
>>
>>- Eliminate r1356317 from history: create an svnsync copy of /repos/asf
>> using an authz file that excludes
>>/lucene/cms/trunk/content/solr/api-4_0_0_ALPHA
>> (or maybe just
>>/lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler/loa
>>der/package-summary.html)
>> and have the Lucene PMC recreate that tag later
>>
>>Thoughts?
>
> I'd lean towards a scripted version of option 1. You could then
> disseminate the script to svnsync mirror admins (like myself), perhaps via
> an ASF/infrastructure blog post?

I think it should be possible to edit the revision file. Changing
"modify-file" to "add-file" would reduce the length of the file but I
think that is OK as all the offsets within the file are to locations
before the change. Or we could use "add-file " with blank padding as
svn_cstring_tokenize will skip the extra blanks.

-- 
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-07-10 11:05:28 CEST

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

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