Some background in case anybody missed it: When we migrated our repository from Tigris to the ASF, some of our mergeinfo got screwed up. Specifically, the mergeinfo ranges didn't always vary by the expected offset of 840074 (see http://svn.apache.org/repos/asf/subversion/README for a concise explanation of the offset).
This mergeinfo problem has been noted in at least two other threads: http://svn.haxx.se/dev/archive-2010-03/0081.shtml http://svn.haxx.se/dev/archive-2009-12/0382.shtml ============================================================ Mike, Do you recall what version of Subversion you used to do the REVISIONIST HISTORY work (http://svn.apache.org/repos/asf/subversion/README)? I'm assuming it was probably 1.6.6, which was the current release at the time, but just wanted to be sure you were not using a trunk build. I retraced* (using 1.6.6) your steps as documented in the README. Mostly I ended up with exactly what you did in the svn-complete repos (http://svn.collab.net/tmp/subversion-data-backup/subversion-history-20091115.tar.bz2). The differences I found were in the mergeinfo for the following paths: '/branches/1.6.x-r40452' '/branches/1.6.x-r40452/CHANGES' '/branches/fs-successor-ids' '/branches/issue-3242-dev' '/branches/python-3-compatibility' The mergeinfos for these paths in your svn-complete repository were largely *unchanged* from what is found in s.t...@40515. They *should* differ by an offset of 3655 (3654 revisions from the original CVS history pre-self-hosting plus 1 revision for the cleanup you did to remove the old tags and branches). The incorrect offsets of these mergeinfos were maintained when loaded into the ASF repos and so remain incorrect to this day. I say "largely unchanged", because there are a few differences. Looking at the '/branches/1.6.x-r40452' branch for example, the only part of the mergeinfo that was correctly offset by 3655 was '/trunk:44106-44170' which was '/trunk:40451-40452' on S.T.O., which was the backport merge Stefan did to from trunk to the branch in r40458(r880532). * I didn't use cvs2svn, but rather started with a dump of svn-compl...@3655. Since no mergeinfo existed at this point it seemed a reasonable shortcut (that, and I didn't want to spend the time figuring out cvs2svn). ============================================================ There is also another bit of weirdness when looking at the mergeinfo on S.T.O. and your svn-complete repository (which I was able to replicate): Self-referential mergeinfo isn't properly adjusted. For example here is the mergeinfo from a branch on S.T.O. (I've snipped all the non-trunk mergeinfo for brevity): C:\SVN\src-branch-1.6.6>svn pg svn:mergeinfo -v file:///C:/SVN/MIRRORS/S.T.O.MIRROR-READ-ONLY/branches/1.5.x-issue2489/CHANGES Properties on 'file:///C:/SVN/MIRRORS/S.T.O.MIRROR-READ-ONLY/branches/1.5.x-issue2489/CHANGES': svn:mergeinfo /trunk/CHANGES:2-1281,29081-31786,31789-32286,32288,32290-32763,32771,32790,32796,32798,32873-32874,32887,32900,32907,32911-32913,32930,32968,32975,32977,33002,33013,33016,33022,33024,33026,33109,33112,33118,33121,33136-33137,33144-33569,33640-33641,33644,33659,33671,33677,33693,33704,33707,33775,33782,33788,33840,33846-34861,34922,34977,34995,35055,35058,35060,35063,35077-35079,35112-35114,35116,35161-35163,35168-35169,35175,35314,35319,35332,35337 Notice above the mergeinfo from trunk for '2-1281'. The 1.5.x. branch was created from tr...@29080, so this is self-referential. We've known some of this has been kicking around our repos, but usually it has been nothing but noise. Here is the same path in in your svn-complete repos: C:\SVN\src-branch-1.6.6>svn pg svn:mergeinfo -v file:///C:/SVN/STO-SAO-MIGRATION/svn-complete/branches/1.5.x-issue2489/CHANGES Properties on 'file:///C:/SVN/STO-SAO-MIGRATION/svn-complete/branches/1.5.x-issue2489/CHANGES': svn:mergeinfo /trunk/CHANGES:2-4936,32736-35441,35444-35941,35943,35945-36418,36426,36445,36451,36453,36528-36529,36542,36555,36562,36566-36568,36585,36623,36630,36632,36657,36668,36671,36677,36679,36681,36764,36767,36773,36776,36791-36792,36799-37224,37295-37296,37299,37314,37326,37332,37348,37359,37362,37430,37437,37443,37495,37501-38516,38577,38632,38650,38710,38713,38715,38718,38732-38734,38767-38769,38771,38816-38818,38823-38824,38830,38969,38974,38987,38992 Notice that the first range is now '2-4936', so the second part of that range is properly adjusted by the 3655 offset, but the first isn't changed at all. Now when we look at this path in the ASF repos, the offsets are both 836419 compared to svn-complete, which is correct as that is the number of revisions that were in ASF repos when the load was done. C:\SVN\src-branch-1.6.6>svn pg svn:mergeinfo -v https://svn.apache.org/repos/asf/subversion/branches/1.5.x-issue2489/CHANGES Properties on 'https://svn.apache.org/repos/asf/subversion/branches/1.5.x-issue2489/CHANGES': svn:mergeinfo subversion/trunk/CHANGES:836421-841355,869155-871860,871863-872360,872362,872364-872837,872845,872864,872870,872872,872947-872948,872961,872974,872981,872985-872987,873004,873042,873049,873051,873076,873087,873090,873096,873098,873100,873183,873186,873192,873195,873210-873211,873218-873643,873714-873715,873718,873733,873745,873751,873767,873778,873781,873849,873856,873862,873914,873920-874935,874996,875051,875069,875129,875132,875134,875137,875151-875153,875186-875188,875190,875235-875237,875242-875243,875249,875388,875393,875406,875411 Still trying to figure out what is going wrong here in the first step. I've only been able to replicate it while doing the multi-hour load of -r1238:40515 from S.T.O., so I need to find a simpler reproduction. ============================================================ The good news, if I can even call it that, is that the second problem shouldn't have any ill effects on our repos. AFAICT it has simply created more self-referential mergeinfo. Yes, I want to know why and fix the bug, but I don't think any cleanup will be necessary in our repos. The first problem is more serious and I'd like to figure out what went wrong when you created svn-complete. We will also need to clean up the mess in the repos, but since I've identified the offending mergeinfos, and they are few, it shouldn't be *too* ugly. Paul
