* subversion/svn/svn.c
  (svn_cl__cmd_table): Document ^/../ relative external syntax. This was
   documented in the svnbook but not mentioned here.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605372 13f79535-47bb-0310-9956-ffa450edef68
Follow-up to r1605123:

* subversion/include/svn_types.h
  (SVN_STR_TO_EOL): Point to the private alternative svn__strol() from
    a private (non-doxygen'd) docstring.

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605375 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_fs_fs/fs_fs.c
  (write_revision_zero): Add a bit of commentary to the length constants.
                         No functional change.

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605444 13f79535-47bb-0310-9956-ffa450edef68
Drop the workaround for concurrent 'hotcopy' and 'pack' race, because it is
broken in at least one common scenario.  The workaround only applies to FSFS
formats 4-6, because in FSFS 7 these operations are always serialized via the
new 'pack-lock' file.  Prior to this changeset, we were trying to be smart in
this racy situation and tried the following (see hotcopy_revisions()):

 - Say, at some point we are done with copying packed shards and are now
   copying the unpacked revisions one-by-one.

 - We know the source path for the unpacked revision file
   (e.g. /db/revs/1/358).

 - Whenever an attempt to copy that revision file raises an ENOENT error,
   we assume that this happened due to a concurrent pack.  In this case we
   determine the pack location for this revision (/db/revs/1.pack/) and
   copy it (and only it!) instead.

The last step is not good enough, because it might actually render the backup
destination unusable and painful to recover.  For instance, imagine running
'hotcopy' for a fully unpacked source repository with several shards:

    [ unpacked ]    [ unpacked ]      [ always unpacked ]
  0             1000             2000                     2537 (youngest)
                           (min-unpacked-rev)

Now, somewhere in the middle of copying the second shard, we invoke a
concurrent pack.  The hotcopy has a workaround for that.  So it says: "Aha,
this revision I was about to copy got packed in the source.  Fine, just copy
the corresponding (second!) packed shard."  When this hotcopy operation
finishes, the destination would look like this ...

    [ unpacked !!! ]    [ packed ]      [ always unpacked ]
  0                 1000           2000                     2537 (youngest)
                             (min-unpacked-rev)

...and this repository is broken, because it contains unpacked revisions
in the [0, min-unpacked-rev) range.  It is unusable, cannot be automatically
recovered and that is definitely not something one would like to see as a
data backup.

A general solution to this problem would probably mean copying everything
from the start in some cases.  However, having a possibility of a retry loop
in a backup routine seems to be worse than exiting with an ENOENT error
("E720003: Can't open file 'db\revs\2\358' ...").  In the latter case, the
hotcopy destination is still valid, just not up-to-date and one can run the
incremental hotcopy after the packing is done.  As an another alternative, we
could tweak the existing workaround and only permit it for the *last* packed
shard, which should be safe to copy.  However, this would look like we are
trying to solve an edge case of an edge case.

I chose to entirely drop this code.  Backup routine that fails in an edge
case (without wreaking havoc) is a better choice compared to a backup routine
that might work in an edge case, but also might produce broken backups.

* subversion/libsvn_fs_fs/hotcopy.c
  (hotcopy_revisions): Do not attempt to workaround a possible scenario of
    concurrent packing.  Rework the existing comment in order to preserve the
    information about the possible race condition and justify why we no
    longer try to handle it.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605633 13f79535-47bb-0310-9956-ffa450edef68
* win-tests.py
  (javahl test runner): Apply -Xcheck:jni when running tests on debug binaries.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605696 13f79535-47bb-0310-9956-ffa450edef68
Fix the JavaHL class cache implementation to make the code re-entrant.

[in subversion/bindings/javahl/native]
* jniwrapper/jni_object.hpp (ClassCache::get_*):
   Change the factory methods to require a JNI environment parameter.
* jniwrapper/jni_class_cache.cpp
  (ClassCacheImpl::m_env): Remove cached JNI environment.
  (ClassCacheImpl::static_init): Require a JNI environment parameter.
  (ClassCacheImpl::get_*): Likewise.
  (ClassCache::get_*): Update; forward JNI environment to ClassCacheImpl.

* jniwrapper/jni_string_map.hpp
  (BaseMap::Set::impl, BaseMap::Iterator::impl, BaseMap::Entry::impl):
   Require a JNI environment parameter and forward it to the
   ClassCache factory methods.

* AuthnCallback.hpp, AuthnCallback.cpp,
  Credential.hpp, Credential.cpp, EditorCallbacks.hpp,
  ExternalItem.cpp, Prompter.cpp, SubversionException.hpp
  jniwrapper/jni_base.cpp, jniwrapper/jni_channel.hpp,
  jniwrapper/jni_channel.cpp, jniwrapper/jni_io_stream.hpp,
  jniwrapper/jni_list.hpp, jniwrapper/jni_list.cpp,
  jniwrapper/jni_string_map.hpp, jniwrapper/jni_string_map.cpp:
   Update all uses of ClassCache and the static impl factories
   to forward the JNI environment that's already available from
   the Java native method implementations.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605718 13f79535-47bb-0310-9956-ffa450edef68
Remove some instances of invalid dereferencing of local
JNI object references in JavaHL.

[in subversion/bindings/javahl/native]
* RemoteSession.cpp (RemoteSession::open):
   Do not dereference jstring parameters. Remove the now unused
   local variable 'env'.
* RemoteSessionContext.cpp (RemoteSessionContext::activate):
   Do not dereference the jobject parameter.
* org_apache_subversion_javahl_util_ConfigImpl_Category.cpp
  (ImplContext::ImplContext): Do not dereference jstring parameters.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605720 13f79535-47bb-0310-9956-ffa450edef68
Fix a pool lifetime bug in JavaHL.

* subversion/bindings/javahl/native/org_apache_subversion_javahl_util_ConfigLib.cpp
  (SimpleSearchCallback): Build the Java representation of the credential within
   the callback itself, because that's where the pool from which the credentials
   hash was allocated is still valid.
  (Java_org_apache_subversion_javahl_util_ConfigLib_nativeGetCredential,
   Java_org_apache_subversion_javahl_util_ConfigLib_nativeRemoveCredential):
   Just return the credential from the callback instance.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605739 13f79535-47bb-0310-9956-ffa450edef68
Add extra JNI checking to JavaHL test runs.
This really should have been enabled since forever.

* Makefile.in
  (check-tigris-javahl, check-apache-javahl, check-deprecated-authn-javahl):
   Add the -Xcheck:jni option to the JVM parameters.

* subversion/bindings/javahl/tests/org/tigris/subversion/javahl/BasicTests.java
  (BasicTests.CountingProgressListener): New; similar to equivalent class
   in the org.apache... test suite.
  (BasicTests.testDataTransferProgressReport): Do not use an exception to
   notice that progress has been reported. This avoids an otherwise trivial
   warning by triggered the -Xcheck:jni option. The org.apache... test
   suite uses a similar workaround.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605766 13f79535-47bb-0310-9956-ffa450edef68
Add new XFail regression test for a case where 'svn diff' triggers an
assertion.

Found by: stsp

* subversion/tests/cmdline/diff_tests.py
  (diff_deleted_in_move_against_repos): New XFail test.
  (test_list): Add diff_deleted_in_move_against_repos.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605810 13f79535-47bb-0310-9956-ffa450edef68
* subversion/tests/cmdline/diff_tests.py
  (diff_deleted_in_move_against_repos): Extend test with notice ancestry
    mode.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605813 13f79535-47bb-0310-9956-ffa450edef68
Add a new test for multi-path lock/unlock callback returning an error.

* subversion/tests/libsvn_fs/locks-test.c
  (struct lock_many_baton_t): Add count.
  (lock_many_cb): Return error.
  (lock_cb_error): New test.
  (test_funcs): Add new test.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605826 13f79535-47bb-0310-9956-ffa450edef68
Fix diffing locally deleted nodes that happen to be directly below
directories that were copied, but via the default ignore-ancestry
handling processed as if they exist in the repository.
(Yes, hard to explain... see testcase added in r1605810,r1605813)

The more common case of nodes that were deeper below such directories
use the standard local diff code which has much better test coverage.

* subversion/libsvn_wc/diff_editor.c
  (walk_local_nodes_diff): Properly handle svn_wc__db_status_deleted when there
    is no base node.

* subversion/tests/cmdline/diff_tests.py
  (diff_deleted_in_move_against_repos): Remove XFail marker.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605832 13f79535-47bb-0310-9956-ffa450edef68
Add a new XFail test, reproducing a missing node error reported when diffing
a replaced node below a copy or move against a repository location.

Found by: stsp

* subversion/tests/cmdline/diff_tests.py
  (diff_replaced_moved): New test.
  (test_list): Add diff_replaced_moved.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605866 13f79535-47bb-0310-9956-ffa450edef68
Apply a simple tweak which fixes the issue identified in r1605866, when not
noticing ancestry: drive the editor as if it is a checkout for local copies.

* subversion/libsvn_client/diff.c
  (diff_repos_wc): When reporting a copy in ignore ancestry mode, report the
    copy as from r0, to make the repository send all nodes as additions.

* subversion/tests/cmdline/diff_tests.py
  (diff_replaced_moved): Remove XFail marker.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605869 13f79535-47bb-0310-9956-ffa450edef68
Fix a Java 8 compiler warning in JavaHL.

* subversion/bindings/javahl/src/org/apache/subversion/javahl/types/ExternalItem.java
  (ExternalItem.hashCode): Override this method here since equals() was also
   overriden.
  (ExternalItem.serialVersionUID): Update comment.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1605871 13f79535-47bb-0310-9956-ffa450edef68
Log post-commit errors in the Apache error log as well as returning
them to the client.

* subversion/mod_dav_svn/version.c
  (dav_svn__checkin): Log APR_EGENERAL rather than serr->apr_err to
   avoid httpd giving "APR does not understand this error".
  (merge): Log any post-commit error.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1606004 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_ra_serf/options.c
  (capabilities_headers_iterator_callback): Allocate values in
   pool used by hash to fix a problem identified by valgrind. 


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1606009 13f79535-47bb-0310-9956-ffa450edef68
Cleanup unused code related move heuristic detection from command line 
client.

* subversion/svn/cl.h
  (svn_cl__opt_state_t): Remove auto_moves member.
   
* subversion/svn/svn.c
  (svn_cl__longopt_t): Remove opt_auto_moves.
  (svn_cl__options): Remove "--auto-moves" command line option.
  (sub_main): Do not handle opt_auto_moves.

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1606094 13f79535-47bb-0310-9956-ffa450edef68
* subversion/tests/cmdline/getopt_tests_data/svn_help_log_switch_stdout: Adjust
   for removal of heuristic move detection.


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