Trent Nelson wrote on Mon, Jul 09, 2012 at 23:17:28 -0700: > > > On 7/8/12 11:48 AM, "Daniel Shahaf" <d...@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. > > 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. >
Done. > > >>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? > There won't be a need for that: recent version of svnsync refuse to sync r1356317 because of the invariant violation (and I imagine anyone who mirrors the ASF repos uses a recent svnsync), so only svn-master.a.o has the corruption. (Even the EU mirror[1] doesn't have it.) Pending rmuir@'s feedback, then, I'll go ahead and edit the revision file in-place. No change should be needed to any of the svn mirrors. Thanks, Daniel [1] Note that no svn*.apache.org DNS name resolves to the EU mirror right now --- not even svn.eu.a.o. > > Trent. >
