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?)
-Hyrum
Received on 2010-11-19 21:04:37 CET