subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Date Sat, 11 Apr 2015 01:40:53 GMT
On 11.04.2015 02:01, Pete Harlan wrote:
> On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad <> 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:  (One side adds a dir, the other added and
> deleted a dir of the same name)
> PASSED:  (Both sides deleted a common dir.)
> PASSED:  (Both sides added a file with the same name.)
> PASSED:  (One side added a file, the other added
> and deleted the file.)
> PASSED:  (One side added a file via copy, the other
> via creating a new file.)
> PASSED:  (Both sides deleted the same file.)
> PASSED:  (One side edited a file, the other deleted it.)
> PASSED:  (Both sides edited a file in conflicting ways.)
> PASSED:  (Clean merge.)
> FAILED:  (Dir of same name added to both sides.)
> FAILED:  (Same, only one was added via copy the other as new.)
> FAILED:  (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

View raw message