On Fri, Nov 19, 2010 at 2:03 PM, Hyrum K. Wright <hyrum_wri...@mail.utexas.edu> wrote: > On Fri, Nov 19, 2010 at 1:50 PM, Paul Burba <ptbu...@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
