You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2008/07/11 16:28:06 UTC
corrupted working copy after merge
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')
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: corrupted working copy after merge
Posted by Mike A <ma...@monitor.com>.
I was the original reporter of this problem to TortoiseSVN. I just want to
add a point to Stefan's problem summary. Even though the error says "Commit
failed", the repository is updated and, even worse, A/file2 is updated
instead of B/file2.
Stefan Küng 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')
>
>
>
> Stefan
>
> --
> ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
>
>
>
--
View this message in context: http://www.nabble.com/corrupted-working-copy-after-merge-tp18407706p18409338.html
Sent from the Subversion Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: corrupted working copy after merge
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Jul 18, 2008 at 2:56 AM, Vlad Georgescu <vg...@gmail.com> wrote:
> Hi Paul,
>
> Paul Burba wrote:
>>
>> 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).
>>
>
> I looked into this a bit and this is what I discovered:
Thanks for taking a quick look Vlad,
> * reverting r27545 only makes the error go away, the commit still
> changes A/folder/file2 instead of B/folder/file2;
I saw that too (http://subversion.tigris.org/issues/show_bug.cgi?id=3240#desc1).
> * the problem is caused by a combination of the merge setting wrong
> version URL wcprops for the files added in B (like
> '/merge/!svn/ver/3/A/folder/file1', notice the A) and the commit of
> the merge failing to reset them to the correct ones (1.4.x does);
>
> * the final commit uses these incorrect version URLs and changes the
> wrong path; the server then sends a new version URL in the DAV MERGE
> response, but r27545 detects that it's for A/folder/file2 not for
> B/folder/file2 and throws an error;
Last night I discovered the revision which seemingly causes the
underlying problem:
r21616 : Resolve issue #2607: post-commit processing exhibits O(n^2) behavior.
> So, two questions:
>
> 1. Why is the merge not ignoring the wcprops sent by the server?
>
> 2. Why does the 1.5 commit of the merge not restore the wcprops to the
> correct values, like 1.4 does?
Looking into r21616 in light of your comments now (though please feel
free to look too as this is getting into a lot of unfamiliar code for
me).
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: corrupted working copy after merge
Posted by Vlad Georgescu <vg...@gmail.com>.
Hi Paul,
Paul Burba wrote:
> 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).
>
I looked into this a bit and this is what I discovered:
* reverting r27545 only makes the error go away, the commit still
changes A/folder/file2 instead of B/folder/file2;
* the problem is caused by a combination of the merge setting wrong
version URL wcprops for the files added in B (like
'/merge/!svn/ver/3/A/folder/file1', notice the A) and the commit of
the merge failing to reset them to the correct ones (1.4.x does);
* the final commit uses these incorrect version URLs and changes the
wrong path; the server then sends a new version URL in the DAV MERGE
response, but r27545 detects that it's for A/folder/file2 not for
B/folder/file2 and throws an error;
So, two questions:
1. Why is the merge not ignoring the wcprops sent by the server?
2. Why does the 1.5 commit of the merge not restore the wcprops to the
correct values, like 1.4 does?
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: corrupted working copy after merge
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Jul 16, 2008 at 1:59 PM, Paul Burba <pt...@gmail.com> wrote:
> On Mon, Jul 14, 2008 at 11:04 AM, Paul Burba <pt...@gmail.com> wrote:
>> On Fri, Jul 11, 2008 at 12:28 PM, Stefan Küng <to...@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
Re: corrupted working copy after merge
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Jul 14, 2008 at 11:04 AM, Paul Burba <pt...@gmail.com> wrote:
> On Fri, Jul 11, 2008 at 12:28 PM, Stefan Küng <to...@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.
Paul
Re: corrupted working copy after merge
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Jul 11, 2008 at 12:28 PM, Stefan Küng <to...@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...
Paul