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.O._at_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-complete_at_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 trunk_at_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
Received on 2010-03-06 00:06:42 CET