When constructing the key prefix that we use for key space separation
in FSFS caches,  make sure that the ":" delimiter is not found in any
of the key parts.  Otherwise, we might be able to construct the same
prefix using a different combination of elements.

Normalizing those parts that potentially need it must not limit their
value space, however, as this would again allow for different element
values to result in the same key prefix.

* subversion/libsvn_fs_fs/caching.c
  (normalize_namespace): new utility function
  (read_config,
   svn_fs_fs__initialize_caches): normalize elements of the key prefix


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1462907 13f79535-47bb-0310-9956-ffa450edef68
* subversion/include/svn_fs.h
  (svn_fs_verify): Continue iterating on this function's docstring.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463156 13f79535-47bb-0310-9956-ffa450edef68
Some of the buildbot scripts were not properly reporting an error during the
'clean' phase. Correct this.

Found by: danielsh

* tools/buildbot/slaves/centos/svnclean.sh,
  tools/buildbot/slaves/i686-debian-sarge1/svnclean.sh,
  tools/buildbot/slaves/svn-x64-macosx-gnu-shared-daily-ra_serf/svnclean.sh,
  tools/buildbot/slaves/svn-x64-macosx-gnu-shared/svnclean.sh,
  tools/buildbot/slaves/ubuntu-x64/svnclean.sh
    Exit with an error status if the 'make extraclean' step fails.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463168 13f79535-47bb-0310-9956-ffa450edef68
* subversion/svnlook/svnlook.c:
  (main): Fix a comment that talked about 'svn undo'.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463200 13f79535-47bb-0310-9956-ffa450edef68
Remove some docstring ambiguity, and leave a comment with a suggestion
for a possible future change of behavior.

* subversion/include/svn_repos.h
  (svn_repos_load_fs4, svn_repos_get_fs_build_parser4): Remove @note
    about what might happen when filtering by revision range.  Current
    behavior exactly matches the most naive interpretation of the
    remaining docstrings anyway.

* subversion/libsvn_repos/load-fs-vtable.c
  (new_revision_record): Leave a comment about a different way we
    could handle out-of-range revisions.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463213 13f79535-47bb-0310-9956-ffa450edef68
Support 'svn mergeinfo -rSTART:END' requests where START > END.

Nobody is clamoring for this feature, but the API changes may help me with
an an ongoing issue #4329 'automatic merge uses reintegrate type merge if
source is fully synced' fix.

* subversion/include/svn_client.h

  (svn_client_mergeinfo_log2): Update doc string; previously we didn't
   specify what we did in the case where the start revision was younger
   than the end revision.
 
* subversion/libsvn_client/mergeinfo.c

  (logs_for_mergeinfo_rangelist): Add a new boolean argument signaling that
   the caller wants the merged/eligible revisions from youngest to oldest.

  (svn_client_mergeinfo_log2): Tolerate callers who specify a start revision
   younger than the end revision.  Update call  to
   logs_for_mergeinfo_rangelist.

* subversion/tests/cmdline/mergeinfo_tests.py

  (recursive_mergeinfo): Expand to test the case where merged/eligible
   revisions are requested in youngest to oldest order.

* subversion/tests/cmdline/svntest/actions.py

  (run_and_verify_mergeinfo): Don't sort the expected output, the doc string
   makes no such promises and it prevents us from expecting any output other
   than oldest to youngest.

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463237 13f79535-47bb-0310-9956-ffa450edef68
Teach svn_client_merge_peg5() to do an automatic merge when no revision
ranges are specified, and let 'svn merge' rely on that instead of calling
the dedicated automatic merge APIs.

This leaves the dedicated 'automatic merge' APIs in place for now; we might
want to remove them or make them private.

This reduces the amount of progress feedback displayed when running an
automatic merge with the new '--verbose' option: the two phases that were
introduced by 'Calculating automatic merge' and 'Merging' messages are now
introduced by a single 'Merging' message.

* subversion/include/svn_client.h,
  subversion/libsvn_client/merge.c
  (svn_client_merge_peg5): Do an automatic merge if no revision range is
    specified.
  (svn_client_merge_peg4): Tweak the doc string to account for this change.

* subversion/svn/merge-cmd.c
  (automatic_merge): Delete.
  (run_merge): Don't take special action to handle an automatic merge, let
    the pegged merge code path handle it.

* subversion/tests/cmdline/svntest/deeptrees.py
  (deep_trees_run_tests_scheme_for_merge): To keep the tests working, specify
    a revision range to the merge so that it will still be allowed even when
    using 'ignore ancestry'.  In other words, avoid invoking the automatic
    merge checks.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463250 13f79535-47bb-0310-9956-ffa450edef68
Update JavaHL to use the revised svn_client_merge5 and svn_client_merge_peg5 APIs.

[in subversion/bindings/javahl/src/org/apache/subversion/javahl]
* ISVNClient.java, SVNClient.java (ISVNClient.merge): Add two new
   overloads that match the new svn_client functions.
   In the peg-merge case, allow passing a null revision range.

[in subversion/bindings/javahl/native]
* SVNClient.h, SVNClient.cpp (SVNClient::merge): Update the native implementation
   to accept the new svn_client parameters, and also accept a null revision range.
* org_apache_subversion_javahl_SVNClient.cpp: Update JNI native wrappers.


[in subversion/bindings/javahl/tests/org/apache/subversion/javahl]
* BasicTests.java (BasicTests.testMergeUsingHistoryImpliedRange):
   New test case, verifies that null merge range works as expected.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463271 13f79535-47bb-0310-9956-ffa450edef68
Remove the ability of svn_repos_authz_read2() to handle repos-relative URLs.

This cleans up a case where it was impossible to canonicalize the paths
being passed into it and also ends up removing the need to pass repos_root
into it.  If callers want to support repos-relative URLs then they should
resolve them into absolute file URLs and canonicalize them prior to calling
svn_repos_authz_read2().

* subversion/include/svn_repos.h
  (svn_repos_authz_read2): Remove repos_root argument and adjust documentation
    to account for no longer accepting repos-root URLs.  Also change "a file"
    in the documented formats for path to a dirent to be more precise.

* subversion/libsvn_repos/authz.c
  (authz_retrieve_config_repo, svn_repos__authz_read, svn_repos_authz_read2):
     Remove repos_root parameter and support for repos-relative URLs in path.

* subversion/libsvn_repos/deprecated.c
  (svn_repos_authz_read): Adjust call of svn_repos__authz_read().

* subversion/libsvn_repos/repos.h
  (svn_repos_authz_read): Adjust declaration and documentation to match the
    removal of repos_root and support for repos-relative URLs.

* subversion/mod_authz_svn/mod_authz_svn.c
  (canonicalize_access_file): Adjust comment about why we are not canonicalizing
    here.
  (get_access_conf): When access_file is a repos-relative URL resolve and
    canonicalize it before calling svn_repos_authz_read2().

* subversion/svnserve/serve.c
  (canonicalize_access_file): Change access_file to an arginout and return
    an svn_error_t so that we can resolve and canonicalize repos-relative
    urls.
  (load_authz_config): Adjust calls to canonicalize_access_file() due to
    above changes.

* subversion/tests/libsvn_repos/repos-test.c
  (in_repo_authz, in_repo_groups_authz): Remove repos-relative URL tests
    and convert still needed tests that were using repos-relative URls to
    absolute URLs.

* tools/server-side/svnauthz.c
  (get_authz): Fix call to svn_repos_authz_read2() to match above changes.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463374 13f79535-47bb-0310-9956-ffa450edef68
Use the absolute URL as the cache_key for repos-relative URLs in
mod_authz_svn.

This fixes what might have been a security problem since two different
repos might have the different authz files at the same path.  If we
use the repos-relative path as a cache_key then the second request
will use the first requests authz file for path based authorization.
Thus potentially allowing an attacker to bypass the authz rules by
making a request against a public repo, followed by a request against
a private repo without closing the connection.  The sort of configuration
that would allow such a thing to happen is precisely what in-repo authz
was intended to allow.

* subversion/mod_authz_svn/mod_authz_svn.c
  (get_access_conf): Move the resolution and canonicalization of a
    repos-relative URL before the determination of the cache_key.



git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463392 13f79535-47bb-0310-9956-ffa450edef68
Allow SVNAuthzGroupsFile to accept repos-relative paths.  Inadvertingly broke
this with r1463374.

* subversion/mod_authz_svn/mod_authz_svn.c
  (resolve_repos_relative_url): Split the logic to resolve a repos-relative
    URL out into a separate function.
  (get_access_conf): Use resolve_repos_relative_url() to resolve repos-relative
    URLs for both the AccessFile and the GroupsFile.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463401 13f79535-47bb-0310-9956-ffa450edef68
Include the groups file in the cache_key for mod_authz_svn.

This prevents a potential security issue.  If we neglected to include the
groups file in the cache key and two repos were configured with the same
authz file but not the same groups file then the groups file would be used
for whichever repo was accessed first in a connection.  Potentially,
allowing a user to escalate the privledges they have on a repo.

* subversion/mod_authz_svn/mod_authz_svn.c
  (get_access_conf): Add groups_file to the cache_key string.



git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463408 13f79535-47bb-0310-9956-ffa450edef68
Be as specific as possible with error messages about loading authz
configurations in mod_authz_svn.

We were saying AuthzSVNAccessFile even when the AuthzSVNReposRelativeAccessFile
directive had been used.  Now that there is a split groups file, we can't be
sure if it was the AccessFile or the GroupsFile directive that had a problem
if svn_repos_authz_read2() failed.

* subversion/mod_authz_svn/mod_authz_svn.c
  (get_access_conf): If we know the configuration directive that failed
    give it.  If not give a generic description.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463410 13f79535-47bb-0310-9956-ffa450edef68
Don't error out with "svn: E200030: sqlite: no such table: nodes"
when opening old working copies and if compiled with SVN_DEBUG.
Instead, print a message advising an upgrade.

I found this problem while trying to use a format 18 WC with a trunk client.

* subversion/libsvn_wc/wc_db_wcroot.c
  (svn_wc__db_wcroot_parse_local_abspath): Verification triggers don't
   install properly with old WC format databases, so ignore sqlite errors
   while installing the triggers. Allows old working copies in 1.7-dev
   format to be upgraded to format 29 (at which point there is yet another
   problem which I'll investigate next).


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463522 13f79535-47bb-0310-9956-ffa450edef68
* subversion/svn/schema/info.rnc
  (attlist.tree-conflict): Add the 'action' and 'reason' values that are new
    in Subversion 1.7 and 1.8.

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463533 13f79535-47bb-0310-9956-ffa450edef68
Follow-up to r1462828: have another try at clarifying the usage of
@a start and @a end in svn_fs_verify.

* subversion/include/svn_fs.h
  (svn_fs_verify): rephrase docstring

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463535 13f79535-47bb-0310-9956-ffa450edef68
Fix WC upgrades from old formats that didn't yet have a NODES table to
format 31 and beyond.

Format 31 introduced a new column in NODES, called inherited_props. When an
svn client which uses format 31 or greater is used to upgrade a pre-NODES WC,
this new column will be created as part of the CREATE TABLE statement which
creates the NODES table.

The format 31 upgrade code would unconditionally attempt to add a new
inherited_props column, which raises an error if the column already exists.

To fix this, check whether the inherited_props column exists before
attempting to create the column. Unfortunately this has to be done
from C as there doesn't seem to be a way of executing an ALTER TABLE
statement based on the result of a PRAGMA table_info() statement.
(If somebody knows a better way of doing this, I welcome any suggestions.)

* subversion/libsvn_wc/wc-metadata.sql
  (STMT_UPGRADE_TO_31): Split this query into two parts, ...
  (STMT_UPGRADE_TO_31_ALTER_TABLE): ... this one, which creates the new
   column and can be skipped if needed, and ...
  (STMT_UPGRADE_TO_31_FINALIZE): ... this one, which runs other upgrade
   statements which are idempotent.

* subversion/libsvn_wc/wc-queries.sql
  (STMT_PRAGMA_TABLE_INFO_NODES): New statement which returns info about
   the NODES table, such as the names of existing columns.

* subversion/libsvn_wc/upgrade.c
  (bump_to_31): Check if the inherited_props column exists before running
   the SQL statement which attempts to create it.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463601 13f79535-47bb-0310-9956-ffa450edef68
* tools/dev/unix-build/Makefile.svn
  (sign-email): Prepare for future SVN releases which don't depend on neon.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463620 13f79535-47bb-0310-9956-ffa450edef68
* tools/dev/unix-build/Makefile.svn
  (sign-email): Fix indentation issue in output.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1463621 13f79535-47bb-0310-9956-ffa450edef68
Fix non-peg merge compatibility wrapper in JavaHL.

[in subversion/bindings/javahl/src/org/apache/subversion/javahl]
* SVNClient.java (SVNClient.merge): Fix silly typo in order of parameters in
   wrapped call to native method.
* ISVNClient.java: Whitespace change, no functional difference.

* subversion/bindings/javahl/native/SVNClient.h (SVNClient::merge):
   Remove extraneous overload declaration.


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