[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: Jacek Materna <jacek_at_assembla.com>
Date: Tue, 9 May 2017 12:58:58 +0200

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
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 <stsp_at_elego.de> 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
Received on 2017-05-09 12:59:05 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.