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
Received on 2016-09-06 11:26:25 CEST