On Sat, Mar 14, 2015 at 7:45 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> Looking further (after turning your test in a regression test), I think this shows another problem. The conflict is on 'dir', not really on file.
>
> But (for legacy reasons) we somehow think that conflicting directory adds are something that we can usually just ignore (because there is no real difference between directories). So the merge of dir is somehow auto resolved, but then still conflicts via file.txt.
>
> If file is not added because there is a conflict on 'dir' that mergeinfo should really be on 'dir' instead of 'dir/file.txt'...
>
> Where also the tree conflict is stored.
>
>
> As the merge determined that 'file.txt' in the working copy, and 'file.txt' as merged are completely different nodes, it should have never changed the unrelated 'file.txt'.
>
> I think this partially answers your question... and shows a real problem.
> (This problem is fixed in r1666690)
>
> The problem is now how would we resolve this in the future:
>
> We still have a tree conflict. One directory with files obstructing another directory with files...
> Or as 'svn info' describes it:
> [[
> Tree conflict: local dir obstruction, incoming dir add upon merge
> Source left: (none) ^/trunk/dir_at_1
> Source right: (dir) ^/trunk/dir_at_4
> ]]
>
> I can see three ways to resolve from this situation:
> * Accept whatever is currently here, as the merged situation. (accept mine-full ?)
> This should just record the merge as happened and then elide with the parent.
> (I thinks this matches your expectation. But it isn't implemented yet)
>
> * Accept that what is merged in should be kept. (accept theirs-full ?)
> This should delete what is currently there. (svn rm --force dir).
> Perform something like 'svn cp ^/trunk/dir_at_4 dir'
> (And then record the merge as happened, by not altering any mergeinfo)
> Also not implemented yet... and depending on the current working copy state possibly dangerous.
>
> * Just delete the tree conflict, and allow the user to apply his own changes
> This is what currently happens with 'accept working'.
>
> I'm not sure what the mergeinfo behavior in this state should be. I just fixed that we at least properly record the mergeinfo on 'dir', but it is possible that not recording mergeinfo is a better option here.
>
> With these three options for resolving I don't see a case where recording the mergeinfo makes complete sense for this particular testcase... accept for allowing the merge to continue where it stopped.
>
> In this specific conflict that can never happen, because dir never received actual changes in either branch or trunk... But in real working copies there might be hundreds of changes on both branches.
>
> Bert
Thank you for the analysis, and for your change! I agree that this is
an improvement: now the directory that is conflicted gets the
svn:mergeinfo property, not each of its contents.
As you pointed out, my original report erroneously focused on
svn:mergeinfo appearing, when the real issue is that the new
svn:mergeinfo doesn't disappear (still) when the user marks the
conflict resolved. (And I haven't found a way to remove it besides
propdel; "svn merge --record-only ^/trunk" has no effect afaict.)
My expectation as a naive user is: I initiated a merge from the root
of a branch (or trunk), I told svn to merge the root of another branch
(or trunk), and I resolved all reported conflicts (however complex).
Unless I've explicitly told svn otherwise, I expect svn to consider
this a full merge, and not create separate mergeinfo for any interior
nodes.
So I think it would be worth updating "svn resolve" to, by default,
take action to trust the user and mark this as a full resolution. If
the user needs to take an extra step or add a new parameter to get
that effect, would that not feel like a regression compared with 1.7?
Thanks,
Pete
Received on 2015-03-15 00:08:02 CET