On 11.04.2015 02:01, Pete Harlan wrote:
> On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad <julianfoad_at_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
Received on 2015-04-11 03:42:11 CEST