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.
Received on 2017-07-19 18:12:56 CEST