On Wed, Jul 16, 2008 at 1:59 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Mon, Jul 14, 2008 at 11:04 AM, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Fri, Jul 11, 2008 at 12:28 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>>> Hi,
>>>
>>> The attached script shows a problem with merging with the 1.5 svn client
>>> against an 1.5 server. The problem does *not* show with file:/// access but
>>> with https:// access to an 1.5 repository. I haven't checked http:// ,
>>> svn:// and svn+ssh:// though, because I don't have such servers ready to
>>> test.
>>>
>>> Client is svn 1.5.0 (r31699), compiled Jun 20 2008, 22:11:29
>>> Server is the same version, running Apache 2.0
>>>
>>> :: script starts here
>>> @echo off
>>> set ROOT=D:/Development/SVN/SVNTests
>>> set SERVERROOT=N:\repos
>>> set REPONAME=merge
>>> set WCNAME=Test6
>>> set REPO=https://192.168.2.5/svn/merge
>>> set WC=%ROOT%/%WCNAME%
>>>
>>> cd %ROOT%
>>> if exist %SERVERROOT%\%REPONAME% rd /s /q %SERVERROOT%\%REPONAME%
>>> if exist %WCNAME% rd /s /q %WCNAME%
>>>
>>> mkdir %SERVERROOT%\%REPONAME%
>>> svnadmin create %SERVERROOT%\%REPONAME%
>>> :: now we have a new repository on http://192.168.2.5/svn/merge
>>>
>>> svn mkdir %REPO%/A -m ""
>>> svn cp %REPO%/A %REPO%/B -m ""
>>> svn co %REPO%/A %WCNAME%\A
>>> svn co %REPO%/B %WCNAME%\B
>>> mkdir %WCNAME%\A\folder
>>> echo x > %WCNAME%\A\folder\file1
>>> echo x > %WCNAME%\A\folder\file2
>>> echo x > %WCNAME%\A\folder\file3
>>> svn add %WCNAME%\A\folder
>>> svn ci %WCNAME%\A -m ""
>>>
>>> svn merge %REPO%/A %WCNAME%\B
>>> svn ci %WCNAME%\B -m ""
>>> echo y > %WCNAME%\B\folder\file2
>>> svn ci %WCNAME%\B -m ""
>>> :: the last commit results in:
>>> :: Transmitting file data .svn: Commit failed (details follow):
>>> :: svn: A MERGE response for '/svn/merge/A/folder/file2' is not a child of
>>> the destination ('/svn/merge/B/folder')
>>
>> Confirmed this error on Windows with a trunk build (r32075) with:
>>
>> http:// (neon)
>> http:// (serf) Segfaults
>>
>> No error with:
>>
>> svn://
>> file://
>>
>> So I could run it with a 1.4.6 client against my trunk server, I
>> changed this line the reproduction script:
>>
>> -svn merge %REPO%/A %WCNAME%\B
>> +svn merge %REPO%/A %WCNAME%\B -r1:HEAD
>>
>> No error with the 1.4.6 client.
>>
>> So looking a bit further it seems this error was introduced in r27545:
>>
>> Fix issue #1851: ra_neon/ra_serf do not update the wcprop cache when
>> committing a working copy of a URL such as http://hostname (i.e. a URL with
>> no path part).
>>
>> * subversion/libsvn_ra_neon/merge.c
>> (merge_ctx_t): Remove the base_len member.
>> (handle_resource): Use svn_path_is_child()/svn_path_is_ancestor() instead
>> of incorrect custom path checks and arithmetic.
>> (svn_ra_neon__merge_activity): Do not initialize the base_len member of the
>> merge_ctx_t structure.
>>
>> * subversion/libsvn_ra_serf/merge.c
>> (svn_ra_serf__merge_context_t): Remove the merge_url_len member.
>> (end_merge): Use svn_path_is_child()/svn_path_is_ancestor() instead of
>> incorrect custom path checks and arithmetic, and return an error instead
>> of calling abort().
>> (svn_ra_serf__merge_create_req): Do not initialize the merge_url_len member
>> of the svn_ra_serf__merge_context_t structure.
>>
>> This is an area of the Subversion code I am not familiar with so I'm
>> uncertain if r27545 is incorrect or simply exposing an existing
>> problem. Looking a bit further now, but if anyone has any thoughts...
>
> Tracking this in http://subversion.tigris.org/issues/show_bug.cgi?id=3240.
This was fixed in r32187 and was backported to 1.5.1 (which is one
Win32 signature short of release at the moment).
Paul
Received on 2008-07-25 17:38:22 CEST