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

Re: Vetoing latest issue #3020 fix in 1.6.10

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 31 Mar 2010 10:28:10 -0400

On Wed, Mar 31, 2010 at 10:13 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
>
>
> On Wed, Mar 31, 2010 at 8:05 AM, Paul Burba <ptburba_at_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
Received on 2010-03-31 16:28:38 CEST

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