On 10/16/05, Philip Martin <philip@codematters.co.uk> wrote:
> 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.
[ snip ]
> 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.
Code on trunk - at least the version I have - ignores ENOENT for
exactly that reason. Is it ignoring the wrong error?
> 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 was actually right now fixing a bug where SVN_WC__LOG_RM forgets to
ignore ENOENT. I looked at SVN_WC__LOG_MV for this behaviour. I
thought SVN_WC__LOG_MV was not susceptable to errors of rerunning.
I'll apply your patch and see what I can do to make them not fail...
As for SVN_WC__LOG_APPEND, that sounds like an operation which never
will be rerunnable. Can't it be emulated differently?
> 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.
This has crossed my mind too, but I'd like to see more of what errors
we currently see, to see if it can't be fixed with the structure we
have now.
bye,
Erik.
Received on Sun Oct 16 20:45:25 2005