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
