[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: stricter text conflicts in 1.10

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 16 May 2017 12:17:14 +0200

On Sat, May 13, 2017 at 10:38 PM, Stefan Fuhrmann <stefan2_at_apache.org> wrote:
> On 09.05.2017 12:14, Stefan Sperling wrote:
>>
>> I have seen several instances of proposals in our STATUS file where I
>> cannot merge without text conflicts because I am using a trunk client.
>>
>> I suppose most of us use 1.9.x clients to do such merges, because
>> otherwise there would be a lot more backport branches in STATUS when
>> nominations get added, and before I run into such a conflict.
>>
>> This is probably due to the stricter text conflict checks added in
>> r1731699.
>> If so, are we really sure that we want to make the new behaviour the
>> default?
>> I can imagine that in organizations with a diverse SVN client install base
>> this change will cause a lot of misunderstandings and confusion among
>> users.
>>
>> And with the conflict resolver we are trying to make tree conflicts less
>> painful. Now, at the same time text conflicts have become a lot more
>> painful
>> than they used to be. I don't think this is going to be a good sell.
>>
> I'm strongly against producing additional text conflicts.
> My feeling is that 1.9 (1.8?) already produces more of
> those than prior releases did and it annoys me.
>
> If we missed a reasonable corner case - by all means
> get that fixed. But don't break the reasonably well
> working cases.

+1. Unless someone has an idea how to improve on r1731699 [1] to avoid
"unnecessary conflicts", I guess we should revert it. Bringing back
the edge case ("controversial behavior discussed in 2003") that
r1731699 fixed is probably the lesser of two evils, compared to the
additional conflicts it introduces.

Bert, WDYT?

[1] http://svn.apache.org/r1731699

-- 
Johan
Received on 2017-05-16 12:17:46 CEST

This is an archived mail posted to the Subversion Dev mailing list.