file obstruction upon merging an already merged added/moved file (#4649)

[Stefan Hett <st...@egosoft.com>]

Hi,

as per stsp's suggestion, sending this to the dev list.

I've reduced a problem we've been having with some merge operations on 
our main repository from time to time down to the repro script attached 
to this JIRA issue [1] (test_obstruction.bat).

Instead of a successful merge, which I'd expect in this case, I get the 
following error instead when doing an svn merge [URL] -cX:
"local file obstruction, incoming file add upon merge"

The test case performs the following steps:
1. create test file and commit
2. modify the file twice and commit each modification separately
3. rename the file and commit
4. merge changes into the branch and commit
5. modify the file on trunk and commit
6. merge the branch back into trunk cherry picking the revision which 
was created in step 4

At this point svn merge produces the error mentioned above.

To me this is unexpected, since I would expect the merge to succeed. In 
the end all I'm doing is merging back the same file into trunk (even 
though in trunk the file was modified).
This looks especially kind of inconsistent to me, since if I do either 
of the following merges instead of a cherry picking merge, the merge 
succeeds without producing any file conflicts:
- "svn merge [URL]" or
- "svn merge [URL]@X+1"

[1] https://issues.apache.org/jira/browse/SVN-4649

-- 
Regards,
Stefan Hett

Re: file obstruction upon merging an already merged added/moved file (#4649)

[Stefan Hett <st...@egosoft.com>]

On 9/10/2016 10:35 AM, Julian Foad wrote:
> Julian Foad wrote:
>> On 06/09/16, Stefan Hett wrote:
>>> What still is unclear to me is that SVN handles the case when I do an
>>> auto merge but not when using the cherry pick merge. [...]
>>
>> An auto merge doesn't try to merge back a revision that it can determine
>> has already been applied to the target branch.
>>
>>> Maybe it's best to have a quick look at this at Berlin, if time 
>>> permits?
>>
>> Sorry, I can't come to Berlin this year [...]
>
> but I'm sure someone else will be glad to go through it with you.
>
k, I'll see to bring it up with someone there.

-- 
Regards,
Stefan Hett

Re: file obstruction upon merging an already merged added/moved file (#4649)

[Julian Foad <ju...@foad.me.uk>]

Julian Foad wrote:
> On 06/09/16, Stefan Hett wrote:
>> What still is unclear to me is that SVN handles the case when I do an
>> auto merge but not when using the cherry pick merge. [...]
>
> An auto merge doesn't try to merge back a revision that it can determine
> has already been applied to the target branch.
>
>> Maybe it's best to have a quick look at this at Berlin, if time permits?
>
> Sorry, I can't come to Berlin this year [...]

but I'm sure someone else will be glad to go through it with you.

- Julian

Re: file obstruction upon merging an already merged added/moved file (#4649)

[Julian Foad <ju...@foad.me.uk>]

On 06/09/16, Stefan Hett wrote:
> What still is unclear to me is that SVN handles the case when I do an
> auto merge but not when using the cherry pick merge. [...]

An auto merge doesn't try to merge back a revision that it can determine 
has already been applied to the target branch.

> Maybe it's best to have a quick look at this at Berlin, if time permits?

Sorry, I can't come to Berlin this year, and only occasionally check 
mail and make a quick reply these days.

- Julian

Re: file obstruction upon merging an already merged added/moved file (#4649)

[Stefan Hett <st...@egosoft.com>]

On 9/5/2016 10:53 PM, Julian Foad wrote:
>
>
> On 05/09/16 10:55, Stefan Hett wrote:
>> On 8/22/2016 5:51 PM, Stefan Hett wrote:
>>> Hi,
>>>
>>> as per stsp's suggestion, sending this to the dev list.
>>>
>>> I've reduced a problem we've been having with some merge operations on
>>> our main repository from time to time down to the repro script
>>> attached to this JIRA issue [1] (test_obstruction.bat).
>>>
>>> Instead of a successful merge, which I'd expect in this case, I get
>>> the following error instead when doing an svn merge [URL] -cX:
>>> "local file obstruction, incoming file add upon merge"
>>>
>>> The test case performs the following steps:
>>> 1. create test file and commit
>>> 2. modify the file twice and commit each modification separately
>>> 3. rename the file and commit
>>> 4. merge changes into the branch and commit
>>> 5. modify the file on trunk and commit
>>> 6. merge the branch back into trunk cherry picking the revision which
>>> was created in step 4
>>>
>>> At this point svn merge produces the error mentioned above.
>>>
>>> To me this is unexpected, since I would expect the merge to succeed.
>>> In the end all I'm doing is merging back the same file into trunk
>>> (even though in trunk the file was modified).
>>> This looks especially kind of inconsistent to me, since if I do either
>>> of the following merges instead of a cherry picking merge, the merge
>>> succeeds without producing any file conflicts:
>>> - "svn merge [URL]" or
>>> - "svn merge [URL]@X+1"
>>>
>>> [1] https://issues.apache.org/jira/browse/SVN-4649
>>>
>> Can anybody confirm that the behavior I see is unexpected and considered
>> a bug? Or is this considered by design?
>
> I haven't looked the details of your script, but when you write "all 
> I'm doing is merging back the same file into trunk" this suggests to 
> me you may not be thinking about merge the same way Subversion is 
> designed to do. It's designed to merge two *changes* -- and you 
> suggest the revision you're trying to merge back is "step 4" which is 
> a change that includes the *creation* of a file. It is expected that 
> if you try to merge one set of changes that create a file with another 
> set of changes that also creates that file, then you get a conflict, 
> sometimes called an "add versus add" conflict, or apparently here is 
> called "obstruction".
>
> I hope that helps.
>
It does. I was actually assuming the same.
What still is unclear to me is that SVN handles the case when I do an 
auto merge but not when using the cherry pick merge. Since the cherry 
pick merge merges the full range of the path, I would assume a 
consistent behavior (aka: either both merges fail due to the incoming 
add over existing add problem; or both merges succeed since they 
correctly handle that case). The difference in that behavior is what 
still confuses me.

Maybe it's best to have a quick look at this at Berlin, if time permits?

For the context: We've set up an auto merge system which merges changes 
from a branch back to trunk automatically (based on a flag in the commit 
message). That merge is done using a cherry pick merge of a single 
revision. The situation above is a case I identified where the auto 
merge currently fails.
Hence, I'm now thinking of reconsidering our approach and try a full 
merge prior to doing cherry pick merges (and only revert to the cherry 
pick merge, if a full merge fails (due to some text/tree conflicts)).

-- 
Regards,
Stefan Hett

Re: file obstruction upon merging an already merged added/moved file (#4649)

[Julian Foad <ju...@foad.me.uk>]

On 05/09/16 10:55, Stefan Hett wrote:
> On 8/22/2016 5:51 PM, Stefan Hett wrote:
>> Hi,
>>
>> as per stsp's suggestion, sending this to the dev list.
>>
>> I've reduced a problem we've been having with some merge operations on
>> our main repository from time to time down to the repro script
>> attached to this JIRA issue [1] (test_obstruction.bat).
>>
>> Instead of a successful merge, which I'd expect in this case, I get
>> the following error instead when doing an svn merge [URL] -cX:
>> "local file obstruction, incoming file add upon merge"
>>
>> The test case performs the following steps:
>> 1. create test file and commit
>> 2. modify the file twice and commit each modification separately
>> 3. rename the file and commit
>> 4. merge changes into the branch and commit
>> 5. modify the file on trunk and commit
>> 6. merge the branch back into trunk cherry picking the revision which
>> was created in step 4
>>
>> At this point svn merge produces the error mentioned above.
>>
>> To me this is unexpected, since I would expect the merge to succeed.
>> In the end all I'm doing is merging back the same file into trunk
>> (even though in trunk the file was modified).
>> This looks especially kind of inconsistent to me, since if I do either
>> of the following merges instead of a cherry picking merge, the merge
>> succeeds without producing any file conflicts:
>> - "svn merge [URL]" or
>> - "svn merge [URL]@X+1"
>>
>> [1] https://issues.apache.org/jira/browse/SVN-4649
>>
> Can anybody confirm that the behavior I see is unexpected and considered
> a bug? Or is this considered by design?

I haven't looked the details of your script, but when you write "all I'm 
doing is merging back the same file into trunk" this suggests to me you 
may not be thinking about merge the same way Subversion is designed to 
do. It's designed to merge two *changes* -- and you suggest the revision 
you're trying to merge back is "step 4" which is a change that includes 
the *creation* of a file. It is expected that if you try to merge one 
set of changes that create a file with another set of changes that also 
creates that file, then you get a conflict, sometimes called an "add 
versus add" conflict, or apparently here is called "obstruction".

I hope that helps.

- Julian

Re: file obstruction upon merging an already merged added/moved file (#4649)

[Stefan Hett <st...@egosoft.com>]

On 8/22/2016 5:51 PM, Stefan Hett wrote:
> Hi,
>
> as per stsp's suggestion, sending this to the dev list.
>
> I've reduced a problem we've been having with some merge operations on 
> our main repository from time to time down to the repro script 
> attached to this JIRA issue [1] (test_obstruction.bat).
>
> Instead of a successful merge, which I'd expect in this case, I get 
> the following error instead when doing an svn merge [URL] -cX:
> "local file obstruction, incoming file add upon merge"
>
> The test case performs the following steps:
> 1. create test file and commit
> 2. modify the file twice and commit each modification separately
> 3. rename the file and commit
> 4. merge changes into the branch and commit
> 5. modify the file on trunk and commit
> 6. merge the branch back into trunk cherry picking the revision which 
> was created in step 4
>
> At this point svn merge produces the error mentioned above.
>
> To me this is unexpected, since I would expect the merge to succeed. 
> In the end all I'm doing is merging back the same file into trunk 
> (even though in trunk the file was modified).
> This looks especially kind of inconsistent to me, since if I do either 
> of the following merges instead of a cherry picking merge, the merge 
> succeeds without producing any file conflicts:
> - "svn merge [URL]" or
> - "svn merge [URL]@X+1"
>
> [1] https://issues.apache.org/jira/browse/SVN-4649
>
Can anybody confirm that the behavior I see is unexpected and considered 
a bug? Or is this considered by design?

-- 
Regards,
Stefan Hett