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: >> > Stefan Sperling wrote: >> >> It does not seem possible right now to merge into locally added >> >> files, because the Subversion assumes that the merge target will >> >> always have a corresponding URL in the repository, and errors out. >> >> >> >> With a bit of special-casing during error handling in a few places, >> >> I succeeded in making this use case work: >> > [...] >> > >> > Hi Stefan. In my opinion, Subversion should allow such a merge to be >> > attempted, and the result should be a textual merge like you've done >> > here > [...] >> > 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. Paul
