You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2010/03/05 23:06:08 UTC
S.T.O.-->S.A.O. Migration and Mergeinfo Revision Offsets
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.@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@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@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
Re: S.T.O.-->S.A.O. Migration and Mergeinfo Revision Offsets
Posted by "C. Michael Pilato" <cm...@collab.net>.
Paul Burba wrote:
> This problem wasn't really about self-referential mergeinfo per se,
> rather it was load bug, see the reopened issue #3020:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3020#desc9
>
> These bugs were fixed in
> http://svn.apache.org/viewvc?view=revision&revision=927243 and
> backported to 1.6.10.
Thanks for summarizing update, Paul.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: S.T.O.-->S.A.O. Migration and Mergeinfo Revision Offsets
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Mar 9, 2010 at 9:24 AM, Paul Burba <pt...@gmail.com> wrote:
> On Mon, Mar 8, 2010 at 9:55 AM, C. Michael Pilato <cm...@collab.net> wrote:
>
>> Paul Burba wrote:
>>> 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 don't run trunk Subversion's these days. Trunk can't handle my
>> sparsely-checked-out working copy size.
>>
>> At any rate, it should have been 1.6.6, because I did all that work on
>> svn.collab.net using the Subversion installed there.
>
> That's what I was afraid of. Like I said, I used 1.6.6 in an attempt
> to recreate the problem. Since I couldn't, I'm out of ideas as to
> what went wrong here. I'll work on fixing the mergeinfo in our repos,
> that is about all I can do re the incorrect offsets.
Nothing new to report re what went wrong with the dump-load, but in
http://svn.apache.org/viewvc?view=revision&revision=929295 I fixed the
mergeinfo on the branches that didn't agree with the expected 840074
offset:
'/branches/1.6.x-r40452'
'/branches/1.6.x-r40452/CHANGES'
'/branches/fs-successor-ids'
'/branches/python-3-compatibility'
Note, earlier in this thread I identified '/branches/issue-3242-dev'
as also having the wrong offset, but Mike already fixed this in
http://svn.apache.org/viewvc?view=revision&revision=888932
> I'll also track down the second bug which didn't correctly adjust the
> self-referential offsets.
This problem wasn't really about self-referential mergeinfo per se,
rather it was load bug, see the reopened issue #3020:
http://subversion.tigris.org/issues/show_bug.cgi?id=3020#desc9
These bugs were fixed in
http://svn.apache.org/viewvc?view=revision&revision=927243 and
backported to 1.6.10.
Paul
Re: S.T.O.-->S.A.O. Migration and Mergeinfo Revision Offsets
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Mar 8, 2010 at 9:55 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Paul Burba wrote:
>> 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 don't run trunk Subversion's these days. Trunk can't handle my
> sparsely-checked-out working copy size.
>
> At any rate, it should have been 1.6.6, because I did all that work on
> svn.collab.net using the Subversion installed there.
That's what I was afraid of. Like I said, I used 1.6.6 in an attempt
to recreate the problem. Since I couldn't, I'm out of ideas as to
what went wrong here. I'll work on fixing the mergeinfo in our repos,
that is about all I can do re the incorrect offsets.
I'll also track down the second bug which didn't correctly adjust the
self-referential offsets.
Paul
Re: S.T.O.-->S.A.O. Migration and Mergeinfo Revision Offsets
Posted by "C. Michael Pilato" <cm...@collab.net>.
Paul Burba wrote:
> 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 don't run trunk Subversion's these days. Trunk can't handle my
sparsely-checked-out working copy size.
At any rate, it should have been 1.6.6, because I did all that work on
svn.collab.net using the Subversion installed there.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand