On Thu, Aug 30, 2018 at 10:08:36PM +0000, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, 30 Aug 2018 14:06 +0200:
> > In --non-interactive mode the default value for --accept is 'recommended'.
>
> This is a backwards incompatible change to the semantics of `svn merge
> --non-interactive` (with no other --option flags): A workflow designed
> under 1.9 and trusting svn to obey PEP 20's "In the face of ambiguity,
> refuse the temptation to guess" will find that 1.10 no longer obeys
> that.
Which facts lead you to this conclusion?
The resolver never makes guesses about moves and renames.
It either detects an ancestral relationship between two nodes
in the repository, or it does not. It will only make guesses
where doing so helps with seeding a search for potential
ancestral relationships.
I'm not sure which ambiguity you are talking about exactly.
If you're referring to ambiguous moves (two ancestral copyfrom
connections exist after svn cp A B; svn mv A C; svn commit), then
don't worry. We're quite careful about applying 'recommended' options.
In the case under discussion the resolver would postpone a conflict
when there is ambiguity. The resolver will only recommend a "follow
move + merge" resolution option when only one move is detected.
(I'll note that popular distributed version control systems lack explicit
ancestry links between paths in their data models which forces them to
make guesses about node ancestry; in our case, users stay in control
as long as they use 'svn copy' and 'svn move').
> I don't know how I missed this before the release, and I'm not sure
> what's best to do now, but I wanted to point this out anyway.
I had to adjust some old tree conflict tests to use --accept=postpone
because some merges would suddently produce text conflicts or even
clean merges where the test expected a tree conflict. These tests
are still useful because they verify our ability to detect such
conflicts. But in the real world, what people care about is that
'svn merge' does as much as it can to produce a useful result.
I think your argument about backwards compat falls short because
it ignores the fact that the mere introduction of tree conflicts
in 1.6 was a much more drastic change. Merges which appeared to
"just work" in 1.5 (but were in fact discarding changes) were suddently
flagging conflicts all over place. I would argue that this change in 1.10
is a long overdue step back in the user-friendly direction by making some
merge cases conflict-free which silently discarded changes in 1.5 and
haven't been conflict-free since 1.6.
Granted, we could have required everyone to add --accept=recommended to
their non-interactive merge command lines, but 99% of our users are simply
not going to do that. And then they would see no moves being followed at
all in non-interactive merges.
And most merges are interactive anyway. Many of our users run continuous
integration but only very few of them run non-interactive test merges.
> P.S. If I'd noticed this ahead of the release, I'd probably have suggested
> leaving accept=postpone the default and having the output of 'merge' say
> "You may want to run 'svn resolve --accept=recommended -R ./' now" at
> the end.
In the --non-interactive case I wouldn't assume anyone is paying
enough attention to read such a message.
Received on 2018-08-31 11:41:33 CEST