On Wed, Aug 04, 2010 at 12:32:06PM -0400, Paul Burba wrote:
> On Wed, Aug 4, 2010 at 12:14 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> > On Wed, 2010-08-04 at 11:23 -0400, Paul Burba wrote:
> >> On Wed, Aug 4, 2010 at 10:52 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> >> > if the tree conflict detection policy is "relaxed", and should be a
> >> > tree conflict if the policy is "strict". (Yes, the "tree conflict
> >> > detection policy" switch only exists in my head.)
> >>
> >> I don't follow you there, how would a merge to a file ever be a tree
> >> conflict? Or do you mean if our merge target is an added directory?
> >> Stefan's patch supports that as well.
> >
> > It's a tree conflict because the incoming change is "modification of
> > file FOO" and the local target is a file *named* FOO but ancestrally
> > unrelated to the source file FOO. It's similar to the situation that
> > we'd get if the target branch at one time did have the ancestrally
> > related FOO line on it but that FOO was then deleted and replaced by a
> > new file named FOO.
> >
> > - Julian
>
> Got it, thanks Julian. (Obviously) I'm for the "relaxed" policy then,
> in this use case.
My take on this is that there is no tree conflict on the target itself.
The user has asked Subversion to merge a set of changes into a target
in the working copy. The target happens to be locally added.
The changes being merged might not be ancestrally related to the target,
but that in itself is no reason for a tree conflict to occur.
Subversion should try its best to apply the changes to the merge target
as instructed. There can occur tree conflicts *inside* of the merge target
if it is a locally added directory. But the target itself is just the root
of the tree the merge operation is applying changes to.
Stefan
Received on 2010-08-23 18:44:17 CEST