Make files within the .svn/pristine directory read-only.

Pristine paths are passed to externals tools, such as diff tools, and it is
possible that such tools allow users to edit these files. Pristines shouldn't
be changed so it seems like a good idea to make them read-only by default.

Pristine files are now made writable only while they're being installed
or removed.

* subversion/libsvn_wc/wc_db_pristine.c
  (pristine_install_txn): Make pristine files writable before installation
   (in case a partial or corrupt copy exists), and make them read-only
   after installation.
  (remove_file): Make pristine files writable before removing them.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1611356 13f79535-47bb-0310-9956-ffa450edef68
Follow-up to r1611356: Attempt to fix tree_conflict_tests 23 on Windows.

* subversion/tests/cmdline/tree_conflict_tests.py
  (actual_only_node_behaviour): If shutil.rmtree() fails to delete a path,
    try again after making the path writable.


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1611360 13f79535-47bb-0310-9956-ffa450edef68
Follow-up to r1611356: No need to make pristine files writable for removal.

* subversion/libsvn_wc/wc_db_pristine.c
  (remove_file): svn_io_remove_file2() will remove read-only files, so there's
   no need for us to make pristines writable before removing them.

Suggested by: julianfoad


git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1611368 13f79535-47bb-0310-9956-ffa450edef68
Fix Windows redo loop oddity for named atomics.  As it turns out, the redo
loops for file creation and locking don't play very well with files that
get / got deleted.  This is the root cause for the bad ra_serf performance
when revprop caching has been enabled.

With this patch, we simply use the same lock file scheme as for e.g. lock
files in FSFS, i.e. we auto-create an empty lock file and keep it.

* subversion/libsvn_subr/named_atomic.c
  (mutex_t): Don't keep the lock file open while not holding the lock,
             i.e. the mutex is simply the file name and the pool that
             will contain the actual file lock.
  (lock): Auto-create and lock the file as we do in e.g. FSFS.
  (unlock): Simple pool cleanup now released the lock file.
  (delete_lock_file): Drop.
  (svn_atomic_namespace__create): Update mutex initialization code.

git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1611379 13f79535-47bb-0310-9956-ffa450edef68
Work around for the poor performance of APR reader / writer locks on Windows.
Basically, fall back to 1.7 code on Win32 by using a simple mutex.

This resulted in a 35% increase in throughput for a 'null-export' over
ra_serf from hot SVN caches with revprop caching enabled.  OTOH, this may
cost us some scalability with ra_svn on high-speed (>1Gb) networks.

* subversion/libsvn_subr/cache-membuffer.c
  (USE_SIMPLE_MUTEX): New flag.  Set depending on whether we need to fall
                      back to a simple locking scheme.
  (svn_membuffer_t): Select lock type at compile time.
  (read_lock_cache,
   write_lock_cache,
   force_write_lock_cache,
   unlock_cache): Use the simple mutex lock when selected.
  (svn_cache__membuffer_cache_create): Initialize the correct lock type and
                                       disable the counter_mutex if redundant.

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