Vetoing latest issue #3020 fix in 1.6.10

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.

Paul
Received on 2010-03-31 16:05:50 CEST