On Tue, Jul 18, 2017 at 09:47:36PM +0000, Daniel Shahaf wrote: > Hi, > > I'm working on CHANGES for alpha3. Could I please get a hand on the > following six changes. For each of them: does it need to be listed in > CHANGES? How'd you summarize the user-visible (or API-consumer-visible) > change in a sentence? > > (In one or two case, I also wonder whether backport nominations are in > order, but that's orthogonal to the CHANGES work.) > > > ------------------------------------------------------------------------ > > r1783879 | stsp | 2017-02-21 12:14:01 +0000 (Tue, 21 Feb 2017) | 14 lines > > > > Stop recommending resolution options which follow incoming moves for merges. > > > > It makes sense for update and switch. If merging, however, the user may want > > to apply an incoming edit to the node's old location, e.g. when backporting > > a file edit to an older release branch where the move should not be applied. > > Recommending that the move be applied without user interaction is not > > helpful > > in such a case. Instead, the resolver should offer two options: > > apply the move + edits, or apply edits at the old location. > > The latter option is not yet implemented. > > > > * subversion/libsvn_client/conflicts.c > > (init_wc_move_targets): Only recommend options which follow incoming moves > > for conflicts raised by update and switch operations.
This is not a change relative 1.9. It just changes the default behaviour of the new resolver in a specific use case. No need to mention this. > > ------------------------------------------------------------------------ > > r1797908 | stsp | 2017-06-07 10:40:57 +0000 (Wed, 07 Jun 2017) | 2 lines > > > > * tools/dev/unix-build/Makefile.svn: Add a way to start a write-through > > proxy. There is no need to mention Makefile.svn in CHANGES, ever. It is not even shipped in releases.
