The wc layer uses log files to make it's operations atomic. If an
operation is interrupted the log file gets left behind, and cleanup
can rerun the commands to complete the operation. I added the
following patch to cause log files to get run twice during normal use
and it turns out that lots of log files cannot be rerun, commmon
operations like update fail.
--- subversion/libsvn_wc/log.c (revision 16751)
+++ subversion/libsvn_wc/log.c (working copy)
@@ -1444,6 +1444,11 @@
const char *log_end
= "</wc-log>\n";
+#ifdef RERUN_LOG_FILES
+ int rerun_counter = 2;
+ rerun:
+#endif
+
parser = svn_xml_make_parser (loggy, start_handler, NULL, NULL, pool);
loggy->adm_access = adm_access;
loggy->pool = svn_pool_create (pool);
@@ -1506,6 +1511,11 @@
svn_xml_free_parser (parser);
+#ifdef RERUN_LOG_FILES
+ if (--rerun_counter)
+ goto rerun;
+#endif
+
if (loggy->entries_modified == TRUE)
{
apr_hash_t *entries;
The main problem is SVN_WC__LOG_MV, when the log file is first run
this commands cause the file to get moved and so on a second run the
command fails because the file does not exist. These failures are
serious as they can lead to broken working copies that remain locked,
and cleanup won't help.
I haven't investigated fully but I suspect SVN_WC__LOG_RM has similar
problems to SVN_WC__LOG_MV, and SVN_WC__LOG_APPEND sounds like it
could also cause rerun problems.
I suppose we could add a "rerun" mode to svn_wc__run_log and attempt
to identify and ignore failures that are due to rerunning, but that
opens the possibility that cleanup would accept otherwise buggy log
files. Perhaps we could add an option to cleanup to enable the more
lenient behaviour.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 16 17:25:52 2005