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.f...@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.f...@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
