[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.6.10 up for testing/signing - merge tests failing

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 02 Apr 2010 16:37:30 -0400

C. Michael Pilato wrote:
> OVER NEON:
>
> PASS: merge_tests.py 45: target inherits mergeinfo from nearest ancestor
> PASS: merge_tests.py 77: subtrees added after start of merge range are ok
> PASS: merge_tests.py 79: merge --reintegrate with renamed file on branch
> PASS: merge_tests.py 124: no self referential filtering on added path
> PASS: merge_tests.py 126: merge --reintegrate with subtree mergeinfo
>
> OVER SERF:
>
> FAIL: merge_tests.py 45: target inherits mergeinfo from nearest ancestor
> PASS: merge_tests.py 77: subtrees added after start of merge range are ok
> FAIL: merge_tests.py 79: merge --reintegrate with renamed file on branch
> FAIL: merge_tests.py 124: no self referential filtering on added path
> FAIL: merge_tests.py 126: merge --reintegrate with subtree mergeinfo
>
> Man, as many times as I ran the test suite for those stupid issue #3242
> backports this is really, really surprising. But I can verify that if I run
> the tests right now on the backport branch, they fail in the same way. I'll
> dive in after lunch and see if I can figure out why we (once again) have
> disparity in our supposedly interchangeable WebDAV RA providers.

Once I got into this debugging, I *knew* I'd been here before. The
issue-3242 partial backport stuffs exposed a long-hidden subtle bug in
ra_serf -- a bug I'd already fixed in trunk, but neglected to backport to 1.6.x:

------------------------------------------------------------------------
r880461 | cmpilato | 2009-11-05 13:48:29 -0500 (Thu, 05 Nov 2009) | 9 lines
Changed paths:
   M /subversion/trunk/subversion/libsvn_ra_serf/mergeinfo.c

Fix an obscure buglet in libsvn_ra_serf masked by our typical usage of
svn_ra_get_mergeinfo().

* subversion/libsvn_ra_serf/mergeinfo.c
  (end_element): Don't require that the mergeinfo REPORT response's
    path have any length to it. As those paths are relative to the
    URL at which the REPORT was aimed, it's quite alright for them to
    be the empty string.

------------------------------------------------------------------------

I've since proposed this fix for backport to 1.6.x. Sorry for (somehow)
missing this in my backport testing.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-04-02 22:37:59 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.