On Mon, 2010-08-23 at 18:40 +0100, Julian Foad wrote:
> 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.
But I don't mean to be only negative. Thanks immensely for implementing
this extension, as well as all the other things you're doing, and I
agree it will be useful.
- Julian
Received on 2010-08-23 19:43:15 CEST