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.