Stefan Sperling wrote:
> On Fri, Apr 16, 2010 at 09:45:16AM -0400, Paul Burba wrote:
>> I just double checked this test, running with both a debug and release
>> build, both pass.
>>
>> You probably already noticed, but the dry-run and full-merge outputs
>> are semantically equivalent. The only differences are the ordering of
>> the notifications and that the
>>
>> "--- Merging r5 through r9 into
>> 'svn-test-work/working_copies/merge_tests-63.files':"
>>
>> notification appears twice. This strikes me more as a limitation in
>> our test suite, rather than a problem with Subversion.
>
> Yes, it does not seem to be a serious problem.
> It's not release blocker.
> I do not compile serf support into the subversion binaries for OpenBSD,
> so in any case this test failure won't affect svn users on this platform.
>
> However, it's interesting that the test fails reliably for me with
> fsfs and serf, and passes reliably with bdb and serf.
> That's kind of odd. Maybe the problem is related to the fact that
> I build APR and Subversion without support for threads? I guess ordering
> of notifications with serf is timing dependent? In what way do fsfs
> and bdb differ in this respect? Should we try to hunt down the cause of
> this or just dismiss it as noise and see if it pops up again later?
Actually, I'm really surprised by this result, and can't think of a good
explanation even with Serf's ordering ... characteristics.
Paul, I thought the merge process always handled subtrees before their
parents. And their two different editor drives altogether. Is that not the
case? Is it possible that ra_serf is actually overlapping whole editor
drives? If so, that seems (to me) like a big-time problem in that layer. I
still don't think it should block the release, but it's something I'd want
to see investigated.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-04-16 17:45:53 CEST