* tools/dev/unix-build/Makefile.svn: update to serf 1.3.8


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617454 13f79535-47bb-0310-9956-ffa450edef68
Modify reopen_modify so it demonstrates the FSFS txn_dir_cache
out-of-date problem.

* subversion/tests/libsvn_fs/fs-test.c
  (struct reopen_modify_baton_t): New.
  (reopen_modify_child): New.
  (reopen_modify): Invoke a thread to make second change.
  (test_funcs): Mark reopen_modify WIMP.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617500 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_subr/debug.c
  (debug_vprintf): Increase local buffer size so clients built with
  SQLITE3_DEBUG don't assert in SVN_DBG() because SQL statements exceed
  the buffer size in length.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617507 13f79535-47bb-0310-9956-ffa450edef68
* subversion/tests/libsvn_fs/fs-test.c
  (reopen_modify_child): Add apr_thread_exit to see if it cures the
   APR_INCOMPLETE on Windows.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617523 13f79535-47bb-0310-9956-ffa450edef68
* subversion/tests/libsvn_fs/fs-test.c
  (reopen_modify_child): Have all return paths invoke apr_thread_exit.


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

* subversion/libsvn_fs_fs/fs.c
  (fs_serialized_init): Re-instantiate the comment removed in r1589262.

Found by: kotkov

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617586 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_subr/named_atomic.c
  (svn_atomic_namespace__create): Don't leave the synch infrastructure locked
                                  when there was an error.

Found by: ivan


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617687 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_fs_fs/fs.c
  (uninitialize_fs_struct): There is no error condition - simply return void.
  (fs_hotcopy): Update caller.

Suggested by: stsp

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617688 13f79535-47bb-0310-9956-ffa450edef68
Record the update/switch target revision for missing tree conflicts
victims in the tree conflict description so the revision can always
be retrieved during conflict resolution.

For instance, 'svn info' might show:

Tree conflict: local file edit, incoming file delete or move upon update
  Source  left: (file) ^/trunk/alpha@2
  Source right: (none)

With this change, 'svn info' shows the target revision ("source right')
of the update/switch which recorded the conflict, even if the node
was missing:

Tree conflict: local file edit, incoming file delete or move upon update
  Source  left: (file) ^/trunk/alpha@2
  Source right: (none) @4

There is a slight API change involved which shouldn't affect compatibility.
The semantics of svn_wc_conflict_version_create2() change such that the
conflict victim's repos relpath is allowed to be NULL if the node kind
is 'none'. Previously the API required a canonical path in all cases
and would ASSERT otherwise, a contract which made it impossible to create
conflict versions for nodes which don't exist. The provided revision
number must still be valid in all cases, of course.

* subversion/include/svn_wc.h
  (svn_wc_conflict_version_create2): Update docstring.
   A NULL 'repos_relpath' is now valid if 'kind' is svn_node_none.

* subversion/libsvn_wc/conflicts.c
  (conflict__prepend_location, conflict__read_location): Handle NULL
   repos-relpath fields in conflict description.

* subversion/libsvn_wc/update_editor.c
  (complete_conflict): Create conflict versions for paths which don't exist
   so revision number information will be recorded.

* subversion/libsvn_wc/util.c
  (svn_wc_conflict_version_create2): Accept a NULL repos_relpath if the
   node kind is svn_node_none.

* subversion/svn/util.c
  (svn_cl__node_description): Print an empty path if the victim's kind
   is svn_node_none, instead of printing the ^/... placeholder path.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617909 13f79535-47bb-0310-9956-ffa450edef68
Resolve a 12 second delay on every 'svn' invocation from Windows system
services that don't have access to a writable user profile.
(Try running a svn script from the task scheduler on Windows 2012 R2)

Without this fix we retry creating the %APPDATA%\Subversion directory again
and again, and then continue silently.

The retry loop prevents erroring out from virusscanners and indexers that keep
file handles open, but this can't happen in the create directory case as we
would have waited in the delete preceding the create in relevant cases.

(Found while rebuilding the Windows buildbot last week)

* subversion/libsvn_subr/io.c
  (svn_io_make_dir_recursively,
   dir_make): Don't retry for 12 seconds when creating a directory fails,
    because we are using a directory with an ACL that denies creating
    directories.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617926 13f79535-47bb-0310-9956-ffa450edef68
Revert r1617909 since a better solution to the problem has been found.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617930 13f79535-47bb-0310-9956-ffa450edef68
When flagging a tree conflict involving a deleted entry during update/switch,
record the deleted target path and target revision for use by the conflict
resolver.

This is an alternative fix for the issue addressed by r1617909, which was
reverted in r1617930.

* subversion/libsvn_wc/update_editor.c
  (complete_conflict): Expect a non-null new_repos_relpath. Callers should
   always provide one, even if it matches repos_relpath.
  (delete_entry): Instead of passing a NULL new_repos_relpath, determine
   the deleted target path (which is different in case of update vs. switch)
   so complete_conflict() will record information on it. 


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617932 13f79535-47bb-0310-9956-ffa450edef68
Rename 'action' and 'reason' fields in svn_wc_conflict_description3_t
to 'incoming_change' and 'local_change', respectively. The new names
make it more apparent whether a given change was made in the source
or the target of an operation, especially with tree conflicts.

No functional change.

* subversion/include/svn_wc.h
  (svn_wc_conflict_description3_t): Rename 'action' to 'incoming_change'
   and 'reason' to 'local_change'. Enhance related documentation.

* subversion/libsvn_client/merge.c
  (record_tree_conflict, merge_file_opened, merge_dir_opened): Track renames.

* subversion/libsvn_wc/conflicts.c
  (generate_propconflict, read_tree_conflict_desc,
   read_prop_conflict_descs): Track renames.

* subversion/libsvn_wc/entries.c
  (write_entry): Track rename.

* subversion/libsvn_wc/tree_conflicts.c
  (svn_wc__deserialize_conflict, svn_wc__serialize_conflict,
   svn_wc__add_tree_conflict): Track renames.

* subversion/libsvn_wc/upgrade.c
  (svn_wc__upgrade_conflict_skel_from_raw): Track renames.

* subversion/libsvn_wc/util.c
  (svn_wc_conflict_description_create_text3, svn_wc__cd3_to_cd2): Track renames.

* subversion/tests/libsvn_wc/conflict-data-test.c
  (compare_conflict, tree_conflict_create, test_deserialize_tree_conflict,
   test_serialize_tree_conflict_data): Track renames.

* tools/dev/svnraisetreeconflict/svnraisetreeconflict.c
  (raise_tree_conflict): Track renames.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1617953 13f79535-47bb-0310-9956-ffa450edef68
Rename the 'node_kind' field in svn_wc_conflict_description3_t
to 'local_node_kind'.

No functional change.

* subversion/include/svn_wc.h
  (svn_wc_conflict_description3_t): Rename 'node_kind' to 'local_node_kind'.
   Resolve a question in a comment by explaining where kinds of other nodes
   involved in the conflict can be found.
  (svn_wc_conflict_description_create_tree3): Rename 'node_kind' parameter
   to 'local_node_kind'.

* subversion/libsvn_wc/info.c
  (svn_wc__get_info): Track rename.

* subversion/libsvn_wc/tree_conflicts.c
  (svn_wc__serialize_conflict): Track rename.

* subversion/libsvn_wc/util.c
  (svn_wc_conflict_description_create_text3,
   svn_wc_conflict_description_create_prop3,
   svn_wc__cd3_to_cd2): Track rename.
  (svn_wc_conflict_description_create_tree3): Rename 'node_kind' parameter
   to 'local_node_kind'.

* subversion/tests/libsvn_wc/conflict-data-test.c
  (compare_conflict, test_deserialize_tree_conflict): Track rename.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1618020 13f79535-47bb-0310-9956-ffa450edef68
For tree conflicts flagged during merges, record the proper node kinds
of the the versions of nodes involved in the conflict (the local working
copy node kind, the merge-left node kind, and the merge-right node kind).

Before this change misleading node kind information was recorded.,
For example, nodes which are deleted at the merge-right side of the incoming
change would produce the following conflict information:

Tree conflict: local file edit, incoming file delete or move upon merge
  Source  left: (file) ^/trunk/beta@1
  Source right: (file) ^/branch/beta@3

This is misleading since ^/branche/betas does not exist in r3 since it
was deleted in r2. With this change, the recorded node kind is 'none':

Tree conflict: local file edit, incoming file delete or move upon merge
  Source  left: (file) ^/trunk/beta@1
  Source right: (none) ^/branch/beta@3

* subversion/libsvn_client/merge.c
  (make_conflict_versions): Expect two node kinds, for the left and right
   side of the merge source, instead of just one.
  (merge_dir_baton_t, merge_file_baton_t): Add fields to store node kind
   information for tree conflict victims: tree_conflict_local_node_kind,
   tree_conflict_merge_left_node_kind, and tree_conflict_merge_right_node_kind.
  (record_tree_conflict): Add two node kind parameters for a total of three and
   rename the existing 'node_kind' parameter to 'local_node_kind'.
   Create conflict versions with merge-left/merge-right node kinds. The local
   node kind is used as the victim's node kind in the conflict description.
  (mark_dir_edited, mark_file_edited): Propagate node kind information stored
   in the dir/file baton to record_tree_conflict().
  (merge_file_opened, merge_dir_opened): Fill in all three node kinds involved
   in the conflict.
  (merge_file_changed): Pass merge-left/merge-right node kinds to the
   make_conflict_versions() function. For file edits both are svn_node_file.
  (merge_file_deleted, merge_dir_deleted): Pass all three node kinds involved
   in the conflict to record_tree_conflict().

* subversion/libsvn_wc/tree_conflicts.c
  (svn_wc__serialize_conflict): 'none' is a legal node kind for tree conflicts.
   Adjust an assertion accordingly.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1618024 13f79535-47bb-0310-9956-ffa450edef68
Avoid shared data clashes and false cache key aliasing between repositories
duplicated using 'hotcopy' or created as a result of dump / load cycles.
See the discussion in http://svn.haxx.se/dev/archive-2014-04/0245.shtml
and http://svn.haxx.se/dev/archive-2014-08/0093.shtml

This is not a "scalability issue" (as stated in the first of the referenced
threads), but rather a full-fledged problem.  We have an ability to share
data between different objects pointing to same filesystems.  This sharing
works within a single process boundary; currently we share locks
(svn_mutex__t objects) and certain transaction data.  Accessing this kind of
shared data requires some sort of a key and we used to use a filesystem UUID
for this purpose.  However, this is *not* good enough for at least a couple
of cases.

Filesystem UUIDs aren't really unique for every filesystem an end user might
have, because they get duplicated during hotcopy, naive copy (copy-paste) or
dump / load cycles.  Whenever we have two filesystems with the same UUIDs
open within a single process, the shared data starts clashing and things can
get pretty ugly.  For example, one can experience random errors with parallel
commits to 2 repositories with the same UUID (hosted by Apache HTTP Server).
Another example was recently mitigated by http://svn.apache.org/r1589653 — we
did encounter a deadlock within nested 'svnadmin freeze' commands executed
for two repositories with the same UUID.

Errors that I witnessed include (but might not be limited to):

- Cannot write to the prototype revision file of transaction '392-ax'
  because a previous representation is currently being written by this
  process (SVN_ERR_FS_CORRUPT)

- Can't unlock unknown transaction '392-ax' (SVN_ERR_FS_CORRUPT)

- Recursive locks are not supported (SVN_ERR_RECURSIVE_LOCK)
  # This used to be deadlock prior to http://svn.apache.org/r1591919

Fix the issue by introducing a concept of "instance IDs" on the FS layer.
Basically, this gives us an ability to distinguish filesystem duplicates or
near-duplicates produced via our API.  We can now have different filesystems
with the same "original" UUID, but with different instance IDs.  With this
concept, it is rather easy to get rid of the shared data clashes described
above.  While doing this, also prevent false aliasing for our cache keys by
throwing in the instance ID there as well.  This kind of aliasing is no
better than the shared data clashes — we might encounter a deadly situation
when two entirely different filesystems access each other's cached data due
to the UUID aliasing.

Patch by: stefan2
          me

* subversion/libsvn_fs_fs/fs.h
  (SVN_FS_FS__MIN_INSTANCE_ID_FORMAT): New.
  (fs_fs_data_t.instance_id): New.

* subversion/libsvn_fs_fs/fs_fs.h
  (svn_fs_fs__set_uuid): Add the instance ID parameter.

* subversion/libsvn_fs_fs/fs.c
  (fs_serialized_init): Use an instance ID as a part of the shared data key.
  (fs_set_uuid): New adapter wrapping the svn_fs_fs__set_uuid() function.
    Whenever we set a new UUID, imply that filesystem will be a different
    instance, i.e. have a new unique instance ID.  Strictly speaking, our
    approach should work fine even if we choose to preserve the instance ID
    upon the UUID bump.  However, we stick to the other option — it doesn't
    make any real difference, but is a bit simpler to implement and
    (arguably) fits the concept better.  Resetting a filesystem UUID probably
    implies that the user wants to recreate all identification markers for
    that filesystem, so we might as well generate a new instance ID.
  (fs_vtable): Use the new fs_set_uuid() adapter here.

* subversion/libsvn_fs_fs/fs_fs.c
  (svn_fs_fs__open): Read the instance ID when it is supported by the format.
  (svn_fs_fs__set_uuid): Rework this routine in order to support writing and
    generating instance IDs when required by the filesystem format.
  (upgrade_body, svn_fs_fs__create): Generate a new instance ID when
    necessary.

* subversion/libsvn_fs_fs/hotcopy.c
  (hotcopy_create_empty_dest): Unconditionally generate a new instance ID.

* subversion/libsvn_fs_fs/caching.c
  (svn_fs_fs__initialize_caches, svn_fs_fs__initialize_txn_caches): Use an
    instance ID as a part of the cache key.

* subversion/tests/cmdline/svnadmin_tests.py
  (check_hotcopy_fsfs_fsx): Allow different instance IDs when comparing the
    'db/uuid' file contents.
  (freeze_freeze): Do not change UUID of hotcopy for new formats supporting
    instance IDs.  For new formats, 'svnadmin freeze A (svnadmin freeze B)'
    should not deadlock or error out with SVN_ERR_RECURSIVE_LOCK even if 'A'
    and 'B' share the same UUID.
  (freeze_same_uuid): New (fails without the core change).
  (test_list): Reference the new test.

* subversion/libsvn_fs_fs/structure
  (Layout of the FS directory): Tweak wording for the 'db/uuid' file.
  (Filesystem formats): Shortly list the format specifics of that file.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1618138 13f79535-47bb-0310-9956-ffa450edef68
Follow-up to r1618138:  Correct UUID / ID handling during FS upgrade.

* subversion/libsvn_fs_fs/fs_fs.c
  (read_uuid): Factored out from ...
  (svn_fs_fs__open): ... this.
  (upgrade_body): Actually read the UUID before trying to rewrite it.
                  Always update the instance ID upon upgrade.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1618151 13f79535-47bb-0310-9956-ffa450edef68
* subversion/libsvn_fs_fs/fs.c
  (fs_serialized_init): Docstring wording tweak. No functional change.

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1618153 13f79535-47bb-0310-9956-ffa450edef68
Following up on r1618138, fix Ruby test failure.

* subversion/bindings/swig/ruby/test/test_ra.rb:
  (test_uuid): With the introduction of the instance IDs, the string
    representation of the 'db/uuid' contents does not really have to match
    the result of the svn_ra_get_uuid2() calls.  Fix the failure by entirely
    avoiding the necessity to parse the 'db/uuid' file.  This is nothing more
    than a smoke test, so we might as well compare Svn::Ra::Session.uuid and
    Svn::Fs::FileSystem.uuid.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1618177 13f79535-47bb-0310-9956-ffa450edef68
Correctly handle a situation of an unresolved SQLite dependency in
our gen_win_dependencies.py script, instead of printing a stacktrace
(TypeError: not all arguments converted during string formatting).

* build/generator/gen_win_dependencies.py
  ( _find_sqlite): The error message does not have any '%s' placeholders,
    so there is no need to pass the self.sqlite_path format argument.


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