* subversion/include/svn_config.h: Add a speparate @since marker to every
   SVN_CONFIG_AUTHN_* constant, in preparation for adding more constants.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573594 13f79535-47bb-0310-9956-ffa450edef68
Store human-readable information about SSL certificates in the auth store.

This info will later be displayed by 'svn auth', which currently parses
cached SSL certificates to obtain the same information. This new information
can also be accessed by third party clients more easily.

Suggested by: rhuijben

* subversion/include/svn_config.h
  (SVN_CONFIG_AUTHN_HOSTNAME_KEY,
   SVN_CONFIG_AUTHN_FINGERPRINT_KEY,
   SVN_CONFIG_AUTHN_VALID_FROM_KEY,
   SVN_CONFIG_AUTHN_VALID_UNTIL_KEY,
   SVN_CONFIG_AUTHN_ISSUER_DN_KEY): New hash key contants. Adjust the docstring
    for this group of constants which implied that all contants defined here
    were already present before 1.9.

* subversion/libsvn_subr/ssl_server_trust_providers.c
  (ssl_server_trust_file_first_credentials): When reading a cert hash which
   lacks the new human-readable info, add the info and save the cert.
   The idea is to update existing data if possible. However, in practice
   this function will only be called if verification of a cached cert
   suddenly fails. So in most cases only newly saved certs will have
   human-readable information.
  (ssl_server_trust_file_save_credentials): Save new human-readable cert info.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573625 13f79535-47bb-0310-9956-ffa450edef68
Quote the libtool path in case it contains spaces.

* configure.ac: Quote when definining since sometimes we specify the shell and
    not just the path to libtool.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573676 13f79535-47bb-0310-9956-ffa450edef68
Use human-readable SSL certificate info in 'svn auth'.

* build.conf: Remove dependency of 'svn' on serf.

* subversion/svn/auth-cmd.c
  (SVN_AUTH_PRETTY_PRINT_SSL_CERTS,
   svnauth__cert_info_keys, cert_info_key_map, show_cert_info,
   split_ascii_cert, load_cert, show_ascii_cert, match_cert_info,
   match_ascii_cert): Remove all of this code related to parsing
    SSL certificates with serf.
  (match_credential): Don't match base64-encoded ascii certs. Certs are
   matched based on their human-readable info, if available.
  (list_credential): Display human-readable SSL cert information.
   Don't bother displaying base64-encoded cert data.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573693 13f79535-47bb-0310-9956-ffa450edef68
Make 'svn auth' match SSL hostnames and fingerprints case-insensitively.
Hostnames and fingerprints should have characters from the ASCII range only.

* subversion/svn/auth-cmd.c
  (match_pattern): Add 'caseblind' parameter which triggers case-insensitive
    matching.
  (match_credential): Update caller. Match SSL hostnames and fingerprints
   case-insensitively. Other credential data is matched case-sensitively.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573701 13f79535-47bb-0310-9956-ffa450edef68
* COMMITTERS: Add self (kotkov) as full committer.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573717 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_ra_serf/util.c
  (convert_organisation_to_str): Include the issuer's common name in the
   result string, if present.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573728 13f79535-47bb-0310-9956-ffa450edef68
Add a test for the erroneous 'svnadmin hotcopy' behavior for FSFS format 1/2
repositories with at least one propchange.  Hotcopying these repositories
currently ends up with mismatching node ids in source and destination
db/current files.

* subversion/tests/cmdline/svnadmin_tests.py
  (fsfs_hotcopy_old_with_propchanges): New test for the erroneous 'svnadmin
    hotcopy' behavior.  Marked as XFail.
  (test_list): Add reference to new test.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573730 13f79535-47bb-0310-9956-ffa450edef68
Fix a regression in the way recover and hotcopy behave for old FSFS format 1/2
repositories described in http://svn.haxx.se/dev/archive-2014-01/0089.shtml
and http://svn.haxx.se/dev/archive-2014-01/0160.shtml

In brief, the problem lies in the way the node ids recovery code makes
assumptions about the current state of the db/current file.  Namely, the
svn_fs_fs__find_max_ids() wrapper introduced in r1503742 behaves like this:

  svn_fs_fs__find_max_ids()
    svn_fs_fs__rev_get_root()
      svn_fs_fs__ensure_revision_exists()
        ...
        (checks the presence of the revision by reading
         the most recent db/current file)

This last assumption renders the recovery procedure useless for old
repositories.  The core of the recovery lies in the ability to recreate the
db/current file (which can be missing, out-of-date or even broken) from the
latest revision in the repository.  Thus, requiring the db/current contents
to be valid and up-to-date in order to be able to run the recovery does not
really make sense.  Moreover, it messes up the hotcopy process, which uses
the same recovery code when updating db/current.  In order to update the
db/current, we need to know the node ids.  In order to get these node ids,
we run the recovery, which assumes that the db/current file is up-to-date
(thus creating a cyclic dependency).

This changeset fixes the root cause of the problem by restoring the 1.8.x way
of bootstrapping the node ids recovery.  We need to know the root offset in
the revision file, so this can be achieved by parsing the revision file
trailer without assuming (and even knowing) something about db/current.
Since r1560643, we have two regression tests ensuring that recover and hotcopy
work for old repositories.  However, this changeset fixes another use case
(recovery with missing or invalid db/current) and it would be nice to have a
test checking it.  I splitted the existing recover_fsfs() test into two parts
(for the new and the --compatible-version=1.3 repositories) with the second
part actually being the new regression test.

Finally, with the root cause fixed, we can now drop the first hunk of
r1561427, which is a hotcopy-wide workaround for the erroneous
ensure_revision_exists() assumption.  It works by prestamping the db/current
with a valid revnum and fake node ids (0) in order to be able to execute
the "real" node ids recovery.  This is no longer required.
See http://svn.haxx.se/dev/archive-2014-01/0160.shtml

* subversion/libsvn_fs_fs/recovery.c
  (recover_get_root_offset): New helper function used to retrieve the root
    node-id offset for non-packed revision files (given a revision number).
  (svn_fs_fs__find_max_ids): Use recover_get_root_offset() to get the root
    offset for the node ids recovery.

* subversion/libsvn_fs_fs/hotcopy.c
  (hotcopy_update_current): Do not touch the db/current file before calling
    svn_fs_fs__find_max_ids().

* subversion/tests/cmdline/svnadmin_tests.py
  (recover_fsfs): Move the core of this test into...
  (corrupt_and_recover_db_current): ...this new helper receiving the minor
    version of the server being tested.
  (fsfs_recover_db_current):
    New test.  Calls corrupt_and_recover_db_current() with the default server
    minor version.  This is effectively the same test as recover_fsfs() was.
  (fsfs_recover_old_db_current):
    New test.  Calls corrupt_and_recover_db_current() with the server minor
    version set to 3.
  (test_list): Add references to new tests in place of the old one.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573744 13f79535-47bb-0310-9956-ffa450edef68
* build/run_tests.py: Add missing import, followup to r1573320.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573780 13f79535-47bb-0310-9956-ffa450edef68
Tweak the get_root_changes_offset() routine in order to fix the problems I
identified in http://svn.haxx.se/dev/archive-2014-02/0189.shtml
This changeset fixes the following issues in its implementation:

- It avoids seeking to a negative offset for the scenarios when the revision
  file is smaller than buffer.

- It avoids touching internal svn_stringbuf_t fields (such as DATA and LEN)
  and achieves the wanted behavior using the stringbuf API only.

- We no longer rely on the allocator-specific BLOCKSIZE when determining the
  buffer size for the trailer.  In a theoretical case where the allocator
  allocates huge 2KiB blocks for every stringbuf, we would fail to parse the
  trailer for smaller (< 2KiB) revision files.

- It uses svn_io_file_read_full2() instead of svn_io_file_read() when reading
  the file block with the revision trailer.  svn_io_file_read(), as opposed
  to svn_io_file_read_full2(), can read any number of bytes <= NBYTES before
  exiting.  This essentially means we would fail to parse the revision
  trailer in all scenarios where this function returns without filling
  the buffer.

* subversion/libsvn_fs_fs/cached_data.c
  (get_root_changes_offset): Create the stringbuf around a stack-allocated
    BUFFER.  Do that only when the buffer is filled (thus avoiding the
    necessity to touch the internal stringbuf fields, i.e. DATA, LEN and
    BLOCKSIZE).  Handle the possibility of revision files being smaller than
    the expected trailer block size (64 bytes).  Do not attempt seeking to
    negative file offsets in that case.  Finally, use svn_io_file_read_full2()
    instead of svn_io_file_read() when reading the file contents.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573794 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_wc/deprecated.c
  (svn_wc_read_kind): Remove some commented-out code and an unreached return.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573800 13f79535-47bb-0310-9956-ffa450edef68
* subversion/tests/libsvn_client/mtcc-test.c
  (verify_mtcc_commit): Remove spurious semi-colon.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573801 13f79535-47bb-0310-9956-ffa450edef68
* CHANGES: Update for 1.9.0 changes through r1573801


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573841 13f79535-47bb-0310-9956-ffa450edef68
Follow-up to r1570053: fix ctypes-python binding test.

* subversion/bindings/ctypes-python/test/wc.py
  (test_diff): Per the r1570053 change we no longer report revision 0 for
    non-existent paths.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1573927 13f79535-47bb-0310-9956-ffa450edef68
* subversion/svnserve/svnserve.c
  (is_busy): Fix typo in comment.

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1574023 13f79535-47bb-0310-9956-ffa450edef68
Incorporate documentation and naming feedback gotten for r1554800.
No functional change.

* subversion/include/svn_fs.h
  (svn_fs_node_relation_t): Add references to the values previously
                            used for these relations.  Fix member
                            spelling and docstring typos.
  (svn_fs_node_relation): Just declare the current behavior as the
                          intended one.

* subversion/libsvn_fs_base/tree.c
  (base_node_relation): Adapt to enum member spelling fix.

* subversion/libsvn_fs_fs/tree.c
  (fs_node_relation): Ditto.

* subversion/libsvn_fs_x/tree.c
  (x_node_relation): Ditto.

Suggested by: julianfoad


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1574038 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_fs/fs-loader.c
  (svn_fs_node_relation):  As we recently defined different FS instances
                           to imply unrelated notes, we can replace the
                           somewhat fragile vtable check with a stricter
                           FS comparison.

Suggested by: julianfoad

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1574056 13f79535-47bb-0310-9956-ffa450edef68
Fix compiler errors regarding index values for membuffer cache.

The maximum entries in a membuffer cache is limited to the max value of an
apr_uint32_t.  But does pointer arithmatic to calculate indexes into the
cache.  On 64-bit platforms the pointers are going to be 64-bits wide, so
the calculation will be 64-bits wide.  The results will stay within the
range of the apr_uint32_t so it's safe to just cast these calculations.

* subversion/libsvn_subr/cache-membuffer.c
  (free_spare_group): Cast to apr_uint32_t when calculating first_spare_group.
  (drop_entry): Cast to apr_uint32_t when calculating last_in_group.
  (find_entry): Cast to apr_uint32_t when calculating previous and next on
    group headers.




git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1574128 13f79535-47bb-0310-9956-ffa450edef68
Fix compiler warnings about the size of membuffer cache entries.

Entries in the membuffer cache are limited to a maximum size of the maximum
value of an apr_uint32_t, since cache values larger than that would not be
efficient.  However, our APIs generally use apr_size_t for the size of data
in memory.  apr_size_t may be 64-bits wide on some platforms.

For the convenience of other developers the membuffer APIs take apr_size_t
values and the effort to ensure the cache entries are not larger than
apr_uint32_t is handled by the membuffer cache code itself.  It does this by
calculating the maximum cache entry value and comparing it against the size
of the incoming entry.  This means it is safe to cast the size to the
apr_uint32_t type it uses internally once this check has been completed.

* subversion/libsvn_subr/cache-membuffer.c
  (select_level): Cast to apr_uint32_t when setting dummy_entry.size.
  (membuffer_cache_set_internal, membuffer_cache_set_partial_internal):
    Cast to apr_uint32_t when setting entry->size.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1574132 13f79535-47bb-0310-9956-ffa450edef68