On Wed, Mar 31, 2010 at 10:13 AM, Hyrum K. Wright <hyrum_wri...@mail.utexas.edu> wrote: > > > On Wed, Mar 31, 2010 at 8:05 AM, Paul Burba <ptbu...@gmail.com> wrote: >> >> Mike and I were discussing the changes I made in >> http://svn.apache.org/viewvc?view=revision&revision=927243 to fix >> issue #3020 and which were backported to 1.6.x. There is a regression >> in that fix and I am changing my vote to -1 and pulling it from 1.6.x >> (and today's roll of 1.6.10). >> >> The fix in r927243 addressed the problem of mergeinfo in a partial >> dump of a repository, specifically: >> >> We dump -r(X>1):Y from repos A then load that dump into repos B. If >> there is mergeinfo in the loaded revisions it may refer to revisions < >> X. r927423 strips out these ranges. This is fine if the partial dump >> of repos A is done in one step, e.g, >> >> svnadmin dump reposA -r200:300 > A.200.300.partial.dump >> svnadmin load reposB < A.200.300.partial.dump >> >> because those revisions don't refer to valid history re the >> mergeinfo's merge source. >> >> Unfortunately this fix breaks a (likely much more) common use case: >> Dumping a complete repository in multiple steps and then loading each >> chunk to the new repository, e.g.: >> >> svnadmin dump reposA -r0:100 > A.0.100.dump >> svnadmin dump reposA -r101:200 --incremental > A.101.200.dump >> svnadmin dump reposA -r201:300 --incremental > A.201.300.dump >> >> svnadmin load reposB < A.0.100.dump >> svnadmin load reposB < A.101.200.dump >> svnadmin load reposB < A.201.300.dump >> >> In this case, valid mergeinfo may be filtered from the 2nd and or 3rd >> load. >> >> I'll work on a fix that can handle both use cases, but for now I am >> changing my vote to -1 and reverting this backport. > > And just so folks know, Paul's got the RM's blessing on this.
Reverted http://svn.apache.org/viewvc?view=revision&revision=929548 Now to fix the fix... Paul
