On Mon, 2010-08-23 at 18:43 +0200, Stefan Sperling wrote:
> 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.
You seem to be talking only about the case where the (locally added)
target is the root of the whole merge, and saying that lack of ancestral
relationship between the source node and this target node doesn't
matter. Maybe the user performing the merge is fully aware of what
he/she is doing, which is fine in this simple case. But what about the
general case, where the modification to a locally added node may be
somewhere deep down in a merge that's supposed to be a simple automatic
merge? If such a modification encounters a new local node (that perhaps
replaces an older node that was once related but has since been moved
away or deleted), some people may want that to be raised as a conflict.
Others, especially those who have set up the situation knowingly, may
not. Hence my talking about this choice of behaviour as the "relaxed"
policy option.
- Julian
Received on 2010-08-23 19:41:35 CEST