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.
> ------------------------------------------------------------------------
> r1791794 | stefan2 | 2017-04-18 14:50:07 +0000 (Tue, 18 Apr 2017) | 11 lines
>
> Fix inconsistent handling of FS-related config flags in mod_dav_svn.
>
> * subversion/mod_dav_svn/mod_dav_svn.c
> (dav_svn__get_fulltext_cache_flag,
> dav_svn__get_revprop_cache_flag,
> dav_svn__get_nodeprop_cache_flag,
> dav_svn__get_block_read_flag): Consistently use the get_conf_flag
> function and default to FSFS's current
> defaults.
>
> Found by: julianfoad
> ------------------------------------------------------------------------
> r1795116 | stefan2 | 2017-05-14 20:22:49 +0000 (Sun, 14 May 2017) | 17 lines
>
> Fix issue #4677.
> https://issues.apache.org/jira/browse/SVN-4677 "svn up fails after a file is added, moved, deleted, replaced by a directory, and a file in the directory is deleted"
>
> When non-exitent paths are allowed as a result of a DAG-walk
> (as opposed to creating a "path not found" error on those),
> we may encounter file nodes in the "parent" path. Those are
> not an error but simply an indication that there won't be any
> sub-paths.
>
> * subversion/libsvn_fs_fs/tree.c
> (open_path): If n/a paths are allowed, non-dir parents are, too.
>
> * subversion/libsvn_fs_x/dag_cache.c
> (svn_fs_x__get_dag_path): Same.
>
> * subversion/tests/libsvn_fs/fs-test.c
> (closest_copy_test_svn_4677): Add regression test.
> (test_funcs): Register new test.
> ------------------------------------------------------------------------
> r1795727 | stefan2 | 2017-05-21 20:22:51 +0000 (Sun, 21 May 2017) | 8 lines
>
> Address a minor initialization lib issue in svnmucc.
>
> Clients should always explictly initialize the libraries that they are using.
> This prevents issues during the application tear-down phase.
>
> * subversion/svnmucc/svnmucc.c
> (sub_main): Explicitly initialize the RA layer just like the CL client does.
> ------------------------------------------------------------------------
> 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.
> ------------------------------------------------------------------------
> r1800836 | philip | 2017-07-04 22:37:52 +0000 (Tue, 04 Jul 2017) | 15 lines
>
> Remove some casts when using APR 2 and fix a "missing volatile" bug that
> was uncovered.
>
> * subversion/include/private/svn_dep_compat.h
> (svn_atomic_casptr, svn_atomic_xchgptr): New.
>
> * subversion/libsvn_fs/fs-loader.c
> (struct fs_type_defn): Add missing volatile to vtable element, change
> type to void * to avoid cast (we lose no type safety since we never
> access the value as any other type).
> (get_library_vtable_direct): Remove explicit cast.
>
> * subversion/libsvn_subr/utf.c
> (atomic_swap): Remove explicit cast.
Last but not least, thanks to Evgeny for writing detailed introductory
paragraphs in his log messages, which made it very easy to understand
the high-level behaviour changes (as opposed to the symbol-level
changes, which are less important in the context of writing CHANGES).
Thanks,
Daniel
Received on 2017-07-18 23:47:40 CEST