[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

S.T.O.-->S.A.O. Migration and Mergeinfo Revision Offsets

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 5 Mar 2010 18:06:08 -0500

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:




Do you recall what version of Subversion you used to do the

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

The differences I found were in the mergeinfo for the following paths:


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

* 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
Properties on 'file:///C:/SVN/MIRRORS/S.T.O.MIRROR-READ-ONLY/branches/1.5.x-issue2489/CHANGES':

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
Properties on 'file:///C:/SVN/STO-SAO-MIGRATION/svn-complete/branches/1.5.x-issue2489/CHANGES':

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
Properties on 'https://svn.apache.org/repos/asf/subversion/branches/1.5.x-issue2489/CHANGES':

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

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.

Received on 2010-03-06 00:06:42 CET

This is an archived mail posted to the Subversion Dev mailing list.