On Fri, Nov 19, 2010 at 2:03 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> On Fri, Nov 19, 2010 at 1:50 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> ...
>> I reopened issue #3641 and tweaked the test for that issue to
>> demonstrate this problem, see
>> http://svn.apache.org/viewvc?view=revision&revision=1036978.
>>
>> So what to do about the r1036429 backport nomination? With r1036429
>> in place, the sync of a replace without history within a copy results,
>> as described in my previous post, in a "svnsync: File not found:
>> revision 4, path '/trunk/H/H1/B/lambda'" error. However, without
>> r1036429 the assert in replay.c is triggered, which strikes me as less
>> desirable. Now what about r962378, which added the assert and is
>> already backported? If we remove revert that change, then issue #3641
>> is alive and well on 1.6.x, but there is no assert, both of the
>> 'replaced-within-copied' variants give the 'File not found' error.
>>
>> So unless somebody has a fix coming soon for issue #3641, I think we
>> should either backport r1036429 or veto it *and* revert r962378. The
>> third option, leaving r962378 but not backporting r1036429 seems the
>> worst of all worlds, since we are introducing an assert.
>
> The current 1.6.15 already has a number of important fixes that I'm
> eager to get into our users' hands. If there isn't an iminent fix for
> this issue, let's back out r962378 from the branch, and reroll
> (hopefully today?)
I went ahead and reverse merged the offending revisions in r1037005.
I think we're pretty stable now, and will probably roll 1.6.15 this
evening, barring any reason not to.
-Hyrum
Received on 2010-11-19 21:23:51 CET