On Fri, Apr 10, 2015 at 6:40 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> 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.
Attached. Disclaimer: they were written to optimize the time spent
initially writing them, not reading or maintaining them :-) There's a
lot of copy+pasting here, inconsistent style, etc. I looked at
writing proper tests using your Python framework but wasn't able to
take the time to learn that setup.
Also, written for a Linux+bash environment; not tested anywhere else.
There's a README describing how to run them, but it's basically "runAll.sh
>>> 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.
When I say that Subversion would error out from initiating a new
merge, I don't mean that internally the client couldn't process the
merge in steps, only that the user couldn't initiate a new "svn merge"
command in a repo that is in the middle of an existing merge.
An exception would be if the merge was one where the client stops and
says "please resolve the conflicts and rerun the merge". In that case
the user has to rerun the merge command in a WC that is in a "merging"
state. I can think of two ways of handling that:
a. Record somewhere what "the current merge" is, and allow the user to
perform that and only that merge command, or
b. Require the user to indicate that this is a continuation merge
("svn merge --continue ...").
I prefer #a because there's less chance for the user to continue a
merge incorrectly by adding the wrong arguments. (Or both: if you
recorded what the merge is, then "svn merge --continue" could continue
the merge without the user retyping the rest of the arguments.)
--Pete
Received on 2015-04-13 19:59:05 CEST