fix.patch

--- origsrc/subversion-1.10.0/subversion/libsvn_subr/io.c	2018-04-24 15:58:49.920742300 +0900
+++ src/subversion-1.10.0/subversion/libsvn_subr/io.c	2018-04-24 21:16:56.215447100 +0900
@@ -4294,6 +4294,7 @@ svn_io_file_rename2(const char *from_pat
       status = apr_file_rename(from_path_apr, to_path_apr, pool);
     }
 #elif defined (__CYGWIN__)
+  status = apr_file_rename(from_path_apr, to_path_apr, pool);
   WIN32_RETRY_LOOP(status, apr_file_rename(from_path_apr, to_path_apr, pool));
 #else
   status = apr_file_rename(from_path_apr, to_path_apr, pool);

gistfile1.txt

Reply to <[email protected]>

I'm afraid that this would be caused by the suggestion in my mail: <[email protected]>.
However, this is not the case.
This seems to be a bug in 05-retry-loop.patch.

The first call of the target function must be made before call of WIN32_RETRY_LOOP()
while Cygwin branch of svn_io_file_rename2() calls WIN32_RETRY_LOOP() directly. 

I've not made exhaustive tests but applying the following patch and replacing cygsvn_subr-1-0.dll seems to fix the issues.

--- origsrc/subversion-1.10.0/subversion/libsvn_subr/io.c	2018-04-24 15:58:49.920742300 +0900
+++ src/subversion-1.10.0/subversion/libsvn_subr/io.c	2018-04-24 21:16:56.215447100 +0900
@@ -4294,6 +4294,7 @@ svn_io_file_rename2(const char *from_pat
       status = apr_file_rename(from_path_apr, to_path_apr, pool);
     }
 #elif defined (__CYGWIN__)
+  status = apr_file_rename(from_path_apr, to_path_apr, pool);
   WIN32_RETRY_LOOP(status, apr_file_rename(from_path_apr, to_path_apr, pool));
 #else
   status = apr_file_rename(from_path_apr, to_path_apr, pool);