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
