Problem: svnsync of /repos/asf r1356317 fails with: svnsync: 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'
Using 1.7.0, but tnelson reports the same problem (and I suspect he uses a more recent version). Further investigation points to an added-without-copyfrom tree containing a modified file: [[[ % svn log -qvr r1356317 https://svn.apache.org/repos/asf/ ------------------------------------------------------------------------ r1356317 | rmuir | 2012-07-02 16:13:49 +0000 (Mon, 02 Jul 2012) | 1 line Changed paths: A /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA A /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org A /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache A /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr A /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler A /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler/loader M /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler/loader/package-summary.html .. (some 2000 more additions, all without copyfrom; no changes above api-4_0_0_ALPHA) ------------------------------------------------------------------------ % perl -MAI -e "print the relevant portions of the changed-paths in the revision file" _5.o-1158013.t1356285-tm5g add-dir false false /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA _9.o-1158013.t1356285-tm5g add-dir false false /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org _a.o-1158013.t1356285-tm5g add-dir false false /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache _g.o-1158013.t1356285-tm5g add-dir false false /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr _1u.o-1158013.t1356285-tm5g add-dir false false /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler _2i.o-1158013.t1356285-tm5g add-dir false false /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler/loader _474.o-1158013.t1356285-tm5g modify-file true true /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler/loader/package-summary.html ]]] [[[ % dump-noderev.pl $PWD /lucene/cms/trunk/content/solr/ r1356317 id: a-1154617.o-1158013.r1356317/8041959 type: dir pred: a-1154617.o-1158013.r1325510/1655 count: 46 text: 1356317 8041025 921 921 0a2b8b51c531ce2bda18c36042f741e9 cpath: /lucene/cms/trunk/content/solr copyroot: 1158013 /lucene/cms/trunk/content/solr % dump-noderev.pl $PWD /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/ r1356317 id: 5-1356317.o-1158013.r1356317/8040796 type: dir count: 0 text: 1356317 8039544 1239 1239 ca089f246db49f6379be42e03354d290 cpath: /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA copyroot: 1158013 /lucene/cms/trunk/content/solr % dump-noderev.pl $PWD /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler/loader/package-summary.html r1356317 id: 474-1356317.o-1158013.r1356317/7575027 type: file count: 0 text: 1356317 6384884 1715 6603 b07ff835f1126c3b4020fad39a4a68fc 9c8ea9a62a4a8c9c5e010395aa3430cfce957e58 1356285-tm5g/_475 props: 1356317 7574980 34 0 25e6c2f7558b7484000d4d090dea5b92 cpath: /lucene/cms/trunk/content/solr/api-4_0_0_ALPHA/org/apache/solr/handler/loader/package-summary.html copyroot: 1158013 /lucene/cms/trunk/content/solr % xxd -s 6384884 -l 6 < db/revs/1356/1356317 0616cf4: 4445 4c54 410a DELTA. ]]] The repository in question is fully world-readable --- there are no read restrictions in authz: https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/asf-authorization-template (sorry, committers-only link) The access and operational logs are at people.apache.org:/x1/logarchive/eris/vc/2012/07/02*.bz2 . The commit started at 15:10:56 (rev-file birthtime), with the operational log 'commit' and the access log 'MERGE' entries starting at 16:11:33 and finishing around 16:24:43.5. The first references to r1356317 in the logs are at 16:13:50. (Perhaps the remaining 10 minutes were spent on updating rep-cache.db? We did experience issues (consistent with db corruption) with rep-cache.db on that day.) How can we have a 'modify-file' within an added-without-copyfrom tree? Isn't svnsync correct to complain in this case?
