On Sat, Mar 14, 2015 at 7:45 AM, Bert Huijben <b...@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@1 > Source right: (dir) ^/trunk/dir@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@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
