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

Re: Vetos in 1.6.x branch -- and how they impact trunk

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Wed, 18 May 2011 20:25:06 +0200

On Wed, May 18, 2011 at 6:32 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Tue, May 17, 2011 at 9:48 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>> There are some vetos in the 1.6.x branch that seem like they are
>> questioning the change, not just whether it was a candidate for
>> backport.  What does that mean for trunk and 1.7?  Here are the items
>> I am thinking of (leaving out the items that were vetoed only because
>> they were not considered appropriate for a fix release):
>>  * r921453, r927184, r927243
>>   Fix reopened issue #3020 'Reflect dropped/renumbered revisions in
>>   svn:mergeinfo data during svnadmin load'
>>   Justification:
>>     Prior to this fix, when loading a partial dump with mergeinfo, the
>>     resulting mergeinfo in the target repository could refer to non-existent
>>     revisions or revisions that have nothing to do with the merge source
>>     in the original repository.  The original fix for issue assumed that
>>     the dump stream was for a complete repository.
>>   Notes:
>>     r921453 and 927184 are tests, r927243 is the fix.
>>   Branch:
>>     ^/subversion/branches/1.6.x-issue3020
>>   Votes:
>>     +1: kameshj
>>     -1: pburba (There is a regression with this fix, see
>>         http://svn.haxx.se/dev/archive-2010-03/0716.shtml)
> The primary "fix" for issue #3020, r927243, was reverted on trunk
> (r936387).  Issue #3020 then spawned a slew of partial fixes (25
> separate changes).  A few problems still exist but are not scheduled
> to be fixed, see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3020#desc20.
> I'd like to remove this nomination from STATUS since it makes no sense
> to nominate a change that has been reverted, any objections?

None here.

> P.S. None of these 25 fixes was backported to 1.6.x.  Some are are not
> suitable for backport because they introduce changes to dump's output
> (e.g. r937033) but many probably could be backported.  My memory is a
> bit foggy on this, but IIRC I felt 1.7 was coming "real soon now" so
> held off on backporting (it was/is going to be a bit of a beast to
> backport and review).  Backporting these has remained a low priority
> on my TODO list.  I'm happy to bump it up if we feel that is the right
> course of action.

+0. If folks are asking for it, go ahead, but I'm not too concerned.

Received on 2011-05-18 20:27:01 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.