On Tue, Feb 06, 2007 at 01:44:44PM +0100, Henner Zeller wrote:
> Hi,
> >The last time this was brought up, the consensus seemed to be that this
> >wasn't something we wanted to attempt to clear up.
> >
> >(one reason was that you have no way to know whether the tmp/ directory
> >actually was empty before it was removed)
> >
> >See e.g. http://svn.haxx.se/dev/archive-2006-07/0217.shtml and
> >surrounding thread.
>
> Well, this thread ends in a half religous discussion about error
> checking and if tools should be user friendly, but doesn't really
> address the issue.
>
Well, some of the thread is useful. The basic concept, I thought, was
that if the tmp/ directory has been removed, the administrative area
is essentially corrupt, and so rather than try to deal with the edge
cases we might encounter during repair, we essentially punt and say
'Something broke here'.
As I understood it, 'svn cleanup' is supposed to fix a particular
problem (completing aborted in-progress working-copy transactions, and
in doing so, unlocking the wc); it's not supposed to be a general-purpose
recovery tool.
> If you look at the code, this error occurs while removing the tmp/
> directory unconditionally to create a fresh version of it. So this
> code will in any case remove tmp/ whether there are files or not.
I'm not that familiar with the code myself, but I'm surprised that we
unconditionally remove the contents without checking them first - Erik's
reply [1] in particular seems to indicate that we'd not want to just
recreate the directory unconditionally (plus there's the 'something bad
happened' indicator that I think would be a good idea to retain).
[1] http://svn.haxx.se/dev/archive-2006-07/0283.shtml
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Tue Feb 6 16:24:47 2007