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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
