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:
>> > 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
Received on 2010-08-04 19:32:44 CEST