On 11.04.2015 02:01, Pete Harlan wrote: > On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad <julianf...@btopenworld.com> > wrote: >> Pete Harlan wrote: > ... >>> If you have suggestions for how I could further help this issue along, >>> please let me know. And thanks again very much for your time. >> It would help to catalogue the various cases. Maybe start with an >> premise that a whole tree merge should not generate any subtree >> mergeinfo and start finding the exceptions that currently occur. > I wrote a list of cases I could think of to test, and tested them > against 1.8.13. > > Of the cases I considered and tested, the subtree mergeinfo appeared > if and only if a *directory* node was part of a tree conflict > (regardless of what it conflicted with). "PASSED" here means no > subtree merge info was created, and "FAILED" means it was created. > > In all cases, "svn resolve --accept=working <conflicted path>" was run > prior to looking for subtree mergeinfo. > > PASSED: dir-add-delete.sh (One side adds a dir, the other added and > deleted a dir of the same name) > PASSED: dir-delete-delete.sh (Both sides deleted a common dir.) > PASSED: file-add-add.sh (Both sides added a file with the same name.) > PASSED: file-add-delete.sh (One side added a file, the other added > and deleted the file.) > PASSED: file-copy-add.sh (One side added a file via copy, the other > via creating a new file.) > PASSED: file-delete-delete.sh (Both sides deleted the same file.) > PASSED: file-edit-delete.sh (One side edited a file, the other deleted it.) > PASSED: file-edit-edit.sh (Both sides edited a file in conflicting ways.) > PASSED: no-conflict.sh (Clean merge.) > > FAILED: dir-add-add.sh (Dir of same name added to both sides.) > FAILED: dir-copy-add.sh (Same, only one was added via copy the other as new.) > FAILED: dir-file-add-add.sh (File added to one side, dir of same name > added to other.) > > Current trunk fails the same tests. All tests pass with 1.7.20 and 1.6.23. > > My scripts are Bash scripts similar to the script I originally posted > to this thread. I can share them if you think that would be useful, > or I'm happy to rerun them against other versions upon request.
It would be wonderful if you could share those scripts; it saves time when everyone uses the same test scripts to discuss behaviour, and we'd surely like to incorporate any new scenario into our test suite. >> Another way to help would be to think about how the client could >> present the "WC is in a merged state" notion, and how that would >> affect various operations. Just assume that we can implement it, and >> imagine how it should behave in order to be useful. Is there a hard >> dividing line between "is" and "is not" in a "merged" state for the >> whole WC -- what if we *want* to merge subtrees separately? Does this >> "state" need more degrees of subtlety in some other way too? > When the WC is in a merged state, doesn't it necessarily contain > modifications to the merge-root svn:mergeinfo property? It seems > reasonable to me to have Subversion error out from initiating a new > merge if it is currently in the middle of a merge (as identified by a > modified svn:mergeinfo property), with a message like "You are in the > middle of merging <url> to <WC path>; please complete that before > merging again or revert it with <...>". This does sound like a logical approach. The problem is that what looks like a single merge from the user's perspective can actually be a series of merges, where each merge depends on the results (including locally modified mergeinfo) of the previous merge. Consider the simplest case, with B branched from A in r5, and r10 cherry-picked from B to A. A full merge of r15 from B to A will actually be split into two merges of two revision ranges: [6..9] and [11..15], skipping the already-merged r10. -- Brane
