On Fri, Feb 11, 2011 at 7:07 AM, Julian Foad <julian.f...@wandisco.com> wrote: > On Thu, 2011-02-10 at 12:10 -0500, Paul Burba wrote: >> Hi Neels (or any other tree conflict gurus), >> >> I know you don't have much time for Subversion these days, but if you >> find some time in the near future could you take a look at the tests >> you added in r879162 and combined in r879206 (this test currently >> resides at merge_tree_conflict_tests.py 23 'replace vs. delete >> tree-conflicts'). >> >> I made a few tweaks to the test in r1069145 and r1069158 and it now >> reaches the end of the test and fails. >> >> Currently the test does the following: >> >> 1) Merge a directory replacement onto a locally deleted directory >> >> 2) Merge a directory-replaced-with-a-file onto a locally deleted directory >> >> 3) Repeat the merge of a file-replaced-with-a-directory onto a locally >> deleted directory done in #2, but this time target a subtree of #2's >> target. > > This doesn't repeat anything of #2, it's completely separate.
Ah yes, I missed the fact that the merge was at depth immediates. > #2 directory-replaced-with-a-file onto A/D/H (target A/D depth immed) > #3 file-replaced-with-a-directory onto A/D/G/pi (target A/D/G) > > I would expect to see a fourth case tested too: > > #4 file-replaced-with-a-file onto mu I added that in r1070629 as well as rewriting the test a bit to make it easier to follow. > (The test starts by calling merge_replace_setup() which sets up for all > of these four cases.) > > >> The only effect this has is the change the resulting TC type >> from 'local delete, incoming delete upon merge' to 'local delete, >> incoming replace upon merge'. > > The ideal expectation would be for all three or four cases to report > 'local delete, incoming replace upon merge'. > > I don't know how close we are in implementation to being able to report > these as incoming replacements; it might not be easy. I'm not sure either and at the moment don't plan to go any further than adding an associated issue for this test (issue #3806). Thanks Julian, Paul >> I'm a bit foggy on what we should expect here and the test doesn't >> have an associated issue (I was looking at this in hopes of adding >> one). >> >> Here's what we are currently seeing on trunk: >> >> Case #1: >> >> >svn st -v A\B\E >> RM + C - 4 ? A\B\E >> > local delete, incoming delete upon merge > > That's quite good except it should say "incoming replace". > >> Case #2: >> >> >svn st -v A\D\H >> D C 3 1 jrandom A\D\H >> > local delete, incoming replace upon merge > > That's quite good except it should say "R" not "D". > >> Case #3: >> >> >svn st -v A\D\G >> M 3 1 jrandom A\D\G >> RM + C - 4 ? A\D\G\pi >> > local delete, incoming delete upon merge > > That's quite good except it should say "incoming replace". > > Wierd that in all these cases the "D"/"R" is opposite to the message. > > (Also, I think status should never report "M" in the properties column > of a "R"eplaced node. But that's a separate issue, probably unrelated > to conflicts.) > > - Julian > > >> I was half expecting that the incoming delete of the replacement be >> handled first and all of these be of the 'local delete, incoming >> delete upon merge' variety and have a local status of 'D ', but that >> is neither what the test expects or (obviously) what the results are. >> >> Any insight you have into this is appreciated. If you don't have time >> to look at this, are there any threads where this was discussed or >> particular docs I should be looking at? The only relevant thing I >> could find was the 'Renames and Replacements' section of >> https://svn.apache.org/repos/asf/subversion/trunk/notes/tree-conflicts/resolution.txt, >> but that is somewhat inconclusive. >> >> Thanks, >> >> Paul
