Following up on r1504501, gracefully exit in situations when the APR include
is missing instead of throwing out a cryptic stacktrace ("... local variable
'version_file_path' referenced before assignment").

* build/generator/gen_win_dependencies.py
  (_find_apr): Do not attempt to use the uninitialized 'version_file_path'
    variable in the error message, because we initialize it later.  Just
    stick to the same as in the _find_apr_util_and_expat(), i.e. use the
    hardcoded filename in the error message.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1603901 13f79535-47bb-0310-9956-ffa450edef68
Do not check whether the apu_version.h file exists in the supplied APR-Util
location *twice*.  os.path.isfile(path) implicates os.path.exists(path), so
the second check effectively does nothing.

* build/generator/gen_win_dependencies.py
  (_find_apr_util_and_expat): Only check for the existence of the
    'apu_version.h' once.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1603921 13f79535-47bb-0310-9956-ffa450edef68
Fix another problem in the gen_win_dependencies.py script.  There are some
cases when we want to print a warning about an unresolved dependency, e.g.:
[[[
  WARNING: 'opensslv.h' not found
  Use '--with-openssl' to configure openssl location.
]]]

Prior to this changeset, we would instead end up with printing a stacktrace
("... global name 'show_warning' is not defined") instead of issuing a
warning and continuing to work.  The reason for that is somewhat trivial --
we inconsistently use the names 'show_warning' and 'show_warnings' across
the script and sometimes encounter a situation when the name of the function
argument does not match the name of the variable in its body.  Fix this by
using a consistent naming scheme across the whole script file.

* build/generator/gen_win_dependencies.py
  (_find_httpd, _find_openssl, _find_jdk, _find_swig, _find_serf,
   _find_sasl, _find_libintl): Use 'show_warnings' instead of 'show_warning'
    as the argument names.  The discrepancies are only in the openssl,
    jdk, and swig-related functions, but using a consistent naming scheme
    *everywhere* could probably avoid the same mistakes in the future.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1604039 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_repos/repos.c
  (HOOKS_ENVIRONMENT_TEXT): Add details to the documentation embedded in hooks.

Inspired by: schabi

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1604047 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_fs_fs/transaction.c
  (fold_change): Rename changes parameter to changed_paths for clarity.
   So fold_change(apr_hash_t *changes, const change_t change) becomes:
      fold_change(apr_hash_t *changed_paths, const change_t *change)
   The same parameter name is used by the caller, and the changed_paths
   hash contains svn_fs_path_change2_t structures instead of change_t
   structures. No functional change.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1604128 13f79535-47bb-0310-9956-ffa450edef68
Get rid of the undefined behavior in the 64-bit Windows crash reporter.
There is a coding oversight that has been there since the r866928.
Prior to this changeset, a register dump could look like this:
[[[
  cs=0033  ss=002b  ds=002b  es=0053  fs=002b  gs=002b  ss=cccccccc
                                                        ^^^ (here is the UB)

  ^^^ (these segment registers actually are incorrectly
       mixed up within the fprintf() call);
]]]

* subversion/libsvn_subr/win32_crashrpt.c
  (write_process_info): Fix the problem by using a correct format string
    and ordering the arguments the same way as in the 32-bit code path.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1604131 13f79535-47bb-0310-9956-ffa450edef68
On remove-log-addressing branch: Merge changes from trunk.

git-svn-id: https://svn.apache.org/repos/asf/subversion/branches/remove-log-addressing@1604133 13f79535-47bb-0310-9956-ffa450edef68