[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Julian Foad <julian_at_foad.me.uk>
Date: Mon, 5 Sep 2016 21:53:32 +0100

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
Received on 2016-09-05 22:53:43 CEST

This is an archived mail posted to the Subversion Dev mailing list.