Re: stricter text conflicts in 1.10

[Stefan Sperling]

On Tue, May 23, 2017 at 01:58:13PM +0200, Johan Corveleyn wrote:
> On Tue, May 16, 2017 at 4:03 PM, Bert Huijben  wrote:
> > Feel free to revert my patch until we find a way to limit the consequences.
> > I expect that we also need to fix a few testcases in separate revisions.
> 
> OK, done in r1795861 (revert of r1731699) and followup in r1795871 to
> re-adjust the ruby tests.

Thanks Johan!

Re: stricter text conflicts in 1.10

[Johan Corveleyn]

On Tue, May 16, 2017 at 4:03 PM, Bert Huijben  wrote:
> Feel free to revert my patch until we find a way to limit the consequences.
> I expect that we also need to fix a few testcases in separate revisions.

OK, done in r1795861 (revert of r1731699) and followup in r1795871 to
re-adjust the ruby tests.

-- 
Johan

RE: stricter text conflicts in 1.10

[Bert Huijben]

Feel free to revert my patch until we find a way to limit the consequences. I 
expect that we also need to fix a few testcases in separate revisions.

Bert

Sent from Mail for Windows 10

From: Johan Corveleyn
Sent: dinsdag 16 mei 2017 12:17
To: Subversion Development
Cc: Stefan Fuhrmann; Bert Huijben
Subject: Re: stricter text conflicts in 1.10

On Sat, May 13, 2017 at 10:38 PM, Stefan Fuhrmann <stef...@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

Re: stricter text conflicts in 1.10

[Johan Corveleyn]

On Sat, May 13, 2017 at 10:38 PM, Stefan Fuhrmann  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

Re: stricter text conflicts in 1.10

[Stefan Fuhrmann]

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.

-- Stefan^2.

Re: stricter text conflicts in 1.10

[Johan Corveleyn]

On Tue, May 9, 2017 at 12:14 PM, 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 agree. These conflicts seem unnecessary and that will hurt SVN's usability.

Now, r1731699 [1] also apparently fixed a real issue, reported by a
user long ago. So imho the questions are:

* Was that really an issue, or more a case of "difference of opinion
on possible behaviour for an edge case"?

* If it was an issue, is there another way to fix it, or to improve
the fix, so it doesn't introduce these unnecessary conflicts.

On IRC yesterday Bert said:
"There should be ways to improve this further... and if this becomes a
real problem we should revert the change. I would like to see that
original case fixed, but I not at all costs."

So, can we discuss this further to find a good solution? How to proceed?

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

-- 
Johan

Re: stricter text conflicts in 1.10

[Jacek Materna]

I know for a fact that UX is already a major decision point around choosing
Subversion over modern alternatives.

What have we done in the past? A staggered +1 release model seems worthy
where we announce it in version A [with it disabled] to allow users to
"opt-in".
If the value is there, users will jump on it. We can measure it via feedback.

At some point down the line, opt-in folds into "default" and strict is
the new sheriff
in town. This is a very successful way of introducing incremental
customer facing
changes in the SaaS world - that is proven.

On Tue, May 9, 2017 at 12:14 PM, 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.



-- 

Jacek Materna
CTO

Assembla
210-410-7661