Strange merge behaviour with rc9

Hi Subversion devs,

I've recently stumbled into a problem trying to perform a largish merge
using TortoiseSVN 1.5.0-RC3 (see
http://svn.haxx.se/tsvn/archive-2008-06/0192.shtml). The problem appeared to
be twofold: first of all, TSVN was merging very slowly compared to the SVN
command-line client. This issue os being dealt with by Stefan Küng. The
other problem is that SVN merge is acting in a way I don't understand.

Specifically, it seems that the speed and outcome of

        svn merge --accept postpone -r A:B URL

and

        svn merge --accept postpont -r A:A1 -r A2:A3 ... -r An:B URL

differ quite a lot. In my testcase the range A:B is non-contiguous with
about 60 subranges (A:A1, A2:A3, ..., An:B). The first command runs very
fast (40 sec) and correctly to the end. The second case runs slowly (5
minutes) and ends in an error.

I can somewhat understand the speed problem, but shouldn't the outcomes of
the two commands be the same? The subranges in question represent all the
relevant revisions on URL, ie. there is no reverse cherry picking or
anything like that going on (in fact, the ranges have been obtained by using
the TSVN log output for URL).

The error I'm getting in the second case is

Error: In directory 'd:\va88\uit\libs'
Error: Error processing command 'append' in 'd:\va88\uit\libs'
Error: Missing 'dest' attribute in 'd:\va88\uit\libs'
Error: Error reading spooled REPORT request response

This happens when about 27 submerges have been performed. I have no idea
what 'append' or 'dest' mean here.

I ran both tests using the 1.5.0-rc9 command line client for Windows.

Thanks,
Kari.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-18 23:29:06 CEST