> -----Original Message-----
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: zaterdag 14 maart 2015 13:06
> To: 'Pete Harlan'
> Cc: 'subversion'; pbu...@collab.net; 'Julian Foad'
> Subject: RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in
> subdirs
>
> [CC-ing two Subversion developers that might have more input on this... I'm
> not
> a merge expert :-)]
>
> > -----Original Message-----
> > From: Pete Harlan [mailto:pchpubli...@gmail.com]
> > Sent: zaterdag 14 maart 2015 02:45
> > To: Bert Huijben
> > Cc: subversion
> > Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in
> > subdirs
> >
> > Thank you for your response! This may demonstrate my question more
> > clearly:
> >
> > The script I posted creates an empty trunk and a branch from it, and
> > then creates dir/file.txt in both trunk and branch separately, and
> > then merges trunk to branch, resulting in this tree conflict:
> >
> > % svn st
> > M .
> > C dir
> > > local dir obstruction, incoming dir add upon merge
> > M dir/file.txt
> > Summary of conflicts:
> > Tree conflicts: 1
> >
> > The path dir/file.txt gains an (empty) svn:mergeinfo property that
> > remains after resolving and committing the merge:
> >
> > % svn propget svn:mergeinfo -R
> > . - /trunk:2-4
> > dir/file.txt -
>
> This mergeinformation on 'dir/file' is actually a copy of what was on trunk
> before this merge started, containing everything except the merge that was
> skipped.
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
