RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
From: Bert Huijben <bert_at_qqmail.nl>
Date: Sat, 14 Mar 2015 15:45:34 +0100
> -----Original Message-----
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.
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...
I can see three ways to resolve from this situation:
* Accept that what is merged in should be kept. (accept theirs-full ?)
* Just delete the tree conflict, and allow the user to apply his own changes
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.
This is an archived mail posted to the Subversion Users mailing list.